Commit Scopes
=============

EDB Postgres Distributed (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:`Monitoring commit scopes <Monitoring commit scopes>`  is a more in-depth look at the structure of commit
   scopes and how to define them for your needs.

-  :ref:`Origin groups <Origin 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:`Group commit <Group commit>`  focuses on the Group Commit option, where you can
   define a transaction as done when a group of nodes agrees it’s done.

-  :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.

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

-  :ref:`Administering PGD Proxy <Administering PGD Proxy>`  addresses how to manage a PGD cluster with Group
   Commit in use.

-  :ref:`Limitations <Limitations>`  lists the various combinations of durability options
   that aren’t currently supported or aren’t possible. Refer to this
   before deciding on a durability strategy.

-  :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

  PGD_Features--commit-scopes--overview
  PGD_Features--commit-scopes--durabilityterminology
  PGD_Features--commit-scopes--commit-scopes
  PGD_Features--commit-scopes--origin_groups
  PGD_Features--commit-scopes--commit-scope-rules
  PGD_Features--commit-scopes--comparing
  PGD_Features--commit-scopes--degrading
  PGD_Features--commit-scopes--Commit_Scope_kinds--index
  PGD_Features--commit-scopes--Working_with--index