With the basic output plugin callbacks (eg., begin_cb
,
change_cb
, commit_cb
and
message_cb
) two-phase commit commands like
PREPARE TRANSACTION
, COMMIT PREPARED
and ROLLBACK PREPARED
are not decoded. While the
PREPARE TRANSACTION
is ignored,
COMMIT PREPARED
is decoded as a COMMIT
and ROLLBACK PREPARED
is decoded as a
ROLLBACK
.
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, (begin_prepare_cb
,
prepare_cb
, commit_prepared_cb
,
rollback_prepared_cb
and
stream_prepare_cb
) and an optional callback
(filter_prepare_cb
).
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 begin_prepare_cb
callback.
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
xid
.
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 50.8.2 for the details.