Working with
============

Commit scopes are fully manageable and configurable.

PGD offers a range of synchronous modes to complement its default
asynchronous replication. You use commit scopes to configure these
synchronous modes. Commit scopes are rules that define how PGD handles
synchronous operations and when the system considers a transaction
committed.

Introducing
-----------

- :ref:`Overview of durability options <Overview of durability options>`  introduces the concepts and some of the essential
  terminology that’s used when discussing synchronous commits.

- :ref:`Durability terminology <Durability terminology>`  lists terms used around PGD’s durability options,
  including how to refer to nodes in replication.

- :ref:`Migration to commit scopes <Migration to commit scopes>`  is a more in-depth look at the structure of commit
  scopes and how to define them for your needs.

- :ref:`Predefined commit scopes <Predefined commit scopes>`  lists the pre-defined commit scopes.

- :ref:`Commit scope groups <Commit scope groups>`  introduces the notion of an origin group, and how to
  leverage these when defining commit scopes rules.

- :ref:`Commit scope rules <Commit scope rules>`  looks at the syntax of and how to formulate a commit
  scope rule.

- :ref:`Comparing durability options <Comparing durability options>`  compares how commit scope options behave with regard to
  durability.

- :ref:`Degrading commit scope rules <Degrading commit scope rules>`  shows how to set up a commit scope rule that can
  gracefully degrade to a lower setting in case of timeouts with a
  stricter setting.

Commit scope kinds
------------------

- :ref:`Synchronous Commit <Synchronous Commit>`  is a commit scope mechanism that works in a similar
  fashion to legacy synchronous replication, but from within the commit
  scope framework.

- :ref:`How Quorum Commit works <How Quorum Commit works>`  is the commit scope kind for workloads requiring
  distributed transaction consistency. Quorum Commit guarantees that all
  participating nodes commit together or roll back together, preventing
  conflicts before they occur.

- :ref:`Commit At Most Once <Commit At Most Once>`  focuses on the Commit At Most Once option, in which
  applications take responsibility for verifying that a transaction has
  been committed before retrying. This ensures that their commits only
  happen at most once.

- :ref:`Lag Control <Lag Control>`  looks at the commit scope mechanism which dynamically
  throttle nodes according to the slowest node and regulates how far out
  of sync nodes may go when a database node goes out of service.

- :ref:`Group Commit (legacy) <Group Commit (legacy)>`  focuses on the Group Commit option, where you can
  define a transaction as done when a group of nodes agrees it’s done.

Working with commit scopes
--------------------------

- :ref:`Administering <Administering>`  addresses how to manage a PGD cluster with commit
  scopes in use.

- :ref:`Legacy synchronous replication using PGD <Legacy synchronous replication using PGD>`  shows how you can still access traditional Postgres
  synchronous operations under PGD.

- :ref:`Timing considerations and synchronous replication <Timing considerations and synchronous replication>`  compares legacy replication with PGD’s async and
  synchronous operations, especially the difference in the order by
  which transactions are flushed to disk or made visible.

.. toctree::
  :maxdepth: 3

  DEEP_DIVE--commit-scopes--overview
  DEEP_DIVE--commit-scopes--durabilityterminology
  DEEP_DIVE--commit-scopes--commit-scopes
  DEEP_DIVE--commit-scopes--predefined-commit-scopes
  DEEP_DIVE--commit-scopes--origin_groups
  DEEP_DIVE--commit-scopes--commit-scope-rules
  DEEP_DIVE--commit-scopes--comparing
  DEEP_DIVE--commit-scopes--degrading
  DEEP_DIVE--commit-scopes--COMMIT_SCOPE_KINDS--index
  DEEP_DIVE--commit-scopes--WORKING_WITH--index