With the basic output plugin callbacks (eg.,
message_cb) two-phase commit commands like
COMMIT PREPARED and
ROLLBACK PREPARED are not decoded. While the
PREPARE TRANSACTION is ignored,
COMMIT PREPARED is decoded as a
ROLLBACK PREPARED is decoded as a
To support the streaming of two-phase commands, an output plugin needs to provide additional callbacks. There are multiple two-phase commit callbacks that are required, (
stream_prepare_cb) and an optional callback (
If the output plugin callbacks for decoding two-phase commit commands are provided, then on
PREPARE TRANSACTION, the changes of that transaction are decoded, passed to the output plugin, and the
prepare_cb callback is invoked. This differs from the basic decoding setup where changes are only passed to the output plugin when a transaction is committed. The start of a prepared transaction is indicated by the
When a prepared transaction is rolled back using the
ROLLBACK PREPARED, then the
rollback_prepared_cb callback is invoked and when the prepared transaction is committed using
COMMIT PREPARED, then the
commit_prepared_cb callback is invoked.
Optionally the output plugin can define filtering rules via
filter_prepare_cb to decode only specific transaction in two phases. This can be achieved by pattern matching on the
gid or via lookups using the
The users that want to decode prepared transactions need to be careful about below mentioned points:
If the prepared transaction has locked [user] catalog tables exclusively then decoding prepare can block till the main transaction is committed.
The logical replication solution that builds distributed two phase commit using this feature can deadlock if the prepared transaction has locked [user] catalog tables exclusively. To avoid this users must refrain from having locks on catalog tables (e.g. explicit
LOCK command) in such transactions. See Section 49.8.2 for the details.