49.10. Two-phase Commit Support for Logical Decoding
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 49.8.2 for the details.