2 .\" Title: PREPARE TRANSACTION
3 .\" Author: The PostgreSQL Global Development Group
4 .\" Generator: DocBook XSL Stylesheets vsnapshot <http://docbook.sf.net/>
6 .\" Manual: PostgreSQL 18.0 Documentation
7 .\" Source: PostgreSQL 18.0
10 .TH "PREPARE TRANSACTION" "7" "2025" "PostgreSQL 18.0" "PostgreSQL 18.0 Documentation"
11 .\" -----------------------------------------------------------------
12 .\" * Define some portability stuff
13 .\" -----------------------------------------------------------------
14 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
15 .\" http://bugs.debian.org/507673
16 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
17 .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
20 .\" -----------------------------------------------------------------
21 .\" * set default formatting
22 .\" -----------------------------------------------------------------
23 .\" disable hyphenation
25 .\" disable justification (adjust text to left margin only)
27 .\" -----------------------------------------------------------------
28 .\" * MAIN CONTENT STARTS HERE *
29 .\" -----------------------------------------------------------------
31 PREPARE_TRANSACTION \- prepare the current transaction for two\-phase commit
35 PREPARE TRANSACTION \fItransaction_id\fR
39 \fBPREPARE TRANSACTION\fR
40 prepares the current transaction for two\-phase commit\&. After this command, the transaction is no longer associated with the current session; instead, its state is fully stored on disk, and there is a very high probability that it can be committed successfully, even if a database crash occurs before the commit is requested\&.
42 Once prepared, a transaction can later be committed or rolled back with
45 \fBROLLBACK PREPARED\fR, respectively\&. Those commands can be issued from any session, not only the one that executed the original transaction\&.
47 From the point of view of the issuing session,
48 \fBPREPARE TRANSACTION\fR
51 command: after executing it, there is no active current transaction, and the effects of the prepared transaction are no longer visible\&. (The effects will become visible again if the transaction is committed\&.)
54 \fBPREPARE TRANSACTION\fR
55 command fails for any reason, it becomes a
56 \fBROLLBACK\fR: the current transaction is canceled\&.
61 An arbitrary identifier that later identifies this transaction for
64 \fBROLLBACK PREPARED\fR\&. The identifier must be written as a string literal, and must be less than 200 bytes long\&. It must not be the same as the identifier used for any currently prepared transaction\&.
68 \fBPREPARE TRANSACTION\fR
69 is not intended for use in applications or interactive sessions\&. Its purpose is to allow an external transaction manager to perform atomic global transactions across multiple databases or other transactional resources\&. Unless you\*(Aqre writing a transaction manager, you probably shouldn\*(Aqt be using
70 \fBPREPARE TRANSACTION\fR\&.
72 This command must be used inside a transaction block\&. Use
76 It is not currently allowed to
78 a transaction that has executed any operations involving temporary tables or the session\*(Aqs temporary namespace, created any cursors
79 WITH HOLD, or executed
82 \fBNOTIFY\fR\&. Those features are too tightly tied to the current session to be useful in a transaction to be prepared\&.
84 If the transaction modified any run\-time parameters with
88 option), those effects persist after
89 \fBPREPARE TRANSACTION\fR, and will not be affected by any later
92 \fBROLLBACK PREPARED\fR\&. Thus, in this one respect
93 \fBPREPARE TRANSACTION\fR
99 All currently available prepared transactions are listed in the
107 .nr an-no-space-flag 1
115 It is unwise to leave transactions in the prepared state for a long time\&. This will interfere with the ability of
117 to reclaim storage, and in extreme cases could cause the database to shut down to prevent transaction ID wraparound (see
118 Section\ \&24.1.5)\&. Keep in mind also that the transaction continues to hold whatever locks it held\&. The intended usage of the feature is that a prepared transaction will normally be committed or rolled back as soon as an external transaction manager has verified that other databases are also prepared to commit\&.
120 If you have not set up an external transaction manager to track prepared transactions and ensure they get closed out promptly, it is best to keep the prepared\-transaction feature disabled by setting
121 max_prepared_transactions
122 to zero\&. This will prevent accidental creation of prepared transactions that might then be forgotten and eventually cause problems\&.
127 Prepare the current transaction for two\-phase commit, using
129 as the transaction identifier:
135 PREPARE TRANSACTION \*(Aqfoobar\*(Aq;
142 \fBPREPARE TRANSACTION\fR
145 extension\&. It is intended for use by external transaction management systems, some of which are covered by standards (such as X/Open XA), but the SQL side of those systems is not standardized\&.
147 COMMIT PREPARED (\fBCOMMIT_PREPARED\fR(7)), ROLLBACK PREPARED (\fBROLLBACK_PREPARED\fR(7))