+ 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