- linkend="vacuum-for-multixact-wraparound"/>).
-
-
-
-
-
-
Subtransactions
-
- Subtransactions are started inside transactions, allowing large
- transactions to be broken into smaller units. Subtransactions can
- commit or abort without affecting their parent transactions, allowing
- parent transactions to continue. This allows errors to be handled
- more easily, which is a common application development pattern.
- The word subtransaction is often abbreviated as
- subxact.
-
-
- Subtransactions can be started explicitly using the
- SAVEPOINT command, but can also be started in
- other ways, such as PL/pgSQL's EXCEPTION clause.
- PL/Python and PL/TCL also support explicit subtransactions.
- Subtransactions can also be started from other subtransactions.
- The top-level transaction and its child subtransactions form a
- hierarchy or tree, which is why we refer to the main transaction as
- the top-level transaction.
-
-
- If a subtransaction is assigned a non-virtual transaction ID,
- its transaction ID is referred to as a subxid
.
- Read-only subtransactions are not assigned subxids, but once they
- attempt to write, they will be assigned one. This also causes all of
- a subxid's parents, up to and including the top-level transaction,
- to be assigned non-virtual transaction ids. We ensure that a parent
- xid is always lower than any of its child subxids.
-
-
- The immediate parent xid of each subxid is recorded in the
- pg_subtrans directory. No entry is made for
- top-level xids since they do not have a parent, nor is an entry made
- for read-only subtransactions.
-
-
- When a subtransaction commits, all of its committed child
- subtransactions with subxids will also be considered subcommitted
- in that transaction. When a subtransaction aborts, all of its child
- subtransactions will also be considered aborted.
-
-
- When a top-level transaction with an xid commits, all of its
- subcommitted child subtransactions are also persistently recorded
- as committed in the pg_xact directory. If the
- top-level transaction aborts, all its subtransactions are also aborted,
- even if they were subcommitted.
-
-
- The more subtransactions each transaction keeps open (not
- rolled back or released), the greater the transaction management
- overhead. Up to 64 open subxids are cached in shared memory for
- each backend; after that point, the storage I/O overhead increases
- significantly due to additional lookups of subxid entries in
- pg_subtrans.
-
-
-
-
-
-
Two-Phase Transactions
-
-
PostgreSQL supports a two-phase commit (2PC)
- protocol that allows multiple distributed systems to work together
- in a transactional manner. The commands are PREPARE
- TRANSACTION, COMMIT PREPARED and
- ROLLBACK PREPARED. Two-phase transactions
- are intended for use by external transaction management systems.
-
PostgreSQL follows the features and model
- proposed by the X/Open XA standard, but does not implement some less
- often used aspects.
-
-
- When the user executes PREPARE TRANSACTION, the
- only possible next commands are COMMIT PREPARED
- or ROLLBACK PREPARED. In general, this prepared
- state is intended to be of very short duration, but external
- availability issues might mean transactions stay in this state
- for an extended interval. Short-lived prepared
- transactions are stored only in shared memory and WAL.
- Transactions that span checkpoints are recorded in the
- pg_twophase directory. Transactions
- that are currently prepared can be inspected using
- linkend="view-pg-prepared-xacts">pg_prepared_xacts.
-
-
-
-
projects / postgresql.git / commitdiff