50.10. Поддержка двухфазной фиксации для логического декодирования #
С базовыми обработчиками модуля вывода (например, begin_cb, change_cb, commit_cb и message_cb) такие команды двухфазной фиксации, как PREPARE TRANSACTION, COMMIT PREPARED и ROLLBACK PREPARED, не декодируются. При этом PREPARE TRANSACTION игнорируется, COMMIT PREPARED декодируется как COMMIT, а ROLLBACK PREPARED декодируется как ROLLBACK.
Для поддержки передачи двухфазных команд модуль вывода должен предоставлять дополнительные обработчики. Определены несколько обязательных обработчиков двухфазной фиксации: (begin_prepare_cb, prepare_cb, commit_prepared_cb, rollback_prepared_cb и stream_prepare_cb) и необязательный (filter_prepare_cb).
Если предоставляются обработчики модуля вывода для декодирования команд двухфазной фиксации, то при выполнении PREPARE TRANSACTION декодируются изменения этой транзакции, которые передаются в модуль вывода, и вызывается обработчик prepare_cb. Это отличается от простой схемы декодирования, когда изменения передаются в модуль вывода только при фиксировании транзакции. Начало подготовленной транзакции обозначается вызовом begin_prepare_cb.
Когда подготовленная транзакция откатывается командой ROLLBACK PREPARED, вызывается обработчик rollback_prepared_cb, а когда подготовленная транзакция фиксируется командой COMMIT PREPARED, вызывается обработчик commit_prepared_cb.
Модуль вывода может определять правила фильтрации, воспользовавшись filter_prepare_cb, чтобы декодировать в две фазы только определённые транзакции. Это можно реализовать, сопоставляя с некоторым шаблоном gid или производя поиск по xid.
Реализуя декодирование подготовленных транзакций, следует учитывать следующие моменты:
Если подготовленная транзакция блокирует таблицы каталога (в том числе пользовательские) в исключительном режиме, декодирование PREPARE может заблокироваться, ожидая завершения основной транзакции.
Решение, осуществляющее логическую репликацию, которое организует распределённую двухфазную фиксацию с использованием этой функциональности, может заблокироваться, если подготовленная транзакция в исключительном режиме заблокирует таблицы каталога (в том числе пользовательские). Чтобы избежать этого, пользователи должны воздержаться от блокировок таблиц каталога (например, явной командой
LOCK) в таких транзакциях. За подробностями обратитесь к Подразделу 50.8.2.
50.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
LOCKcommand) in such transactions. See Section 50.8.2 for the details.
