Con las devoluciones de llamada del plugin de salida básica (por ejemplo, begin_cb,
change_cb, commit_cb y message_cb) los comandos de confirmación en
dos fases como PREPARE TRANSACTION, COMMIT PREPARED y ROLLBACK PREPARED
no se decodifican. Mientras que se ignora PREPARE TRANSACTION, COMMIT PREPARED se decodifica
como un COMMIT y ROLLBACK PREPARED se decodifica como un ROLLBACK.
Para admitir la transmisión de comandos en dos fases, un plugin de salida debe proporcionar devoluciones de llamada adicionales.
Existen varias devoluciones de llamada de confirmación en dos fases que son obligatorias (begin_prepare_cb,
prepare_cb, commit_prepared_cb, rollback_prepared_cb y
stream_prepare_cb) y una devolución de llamada opcional (filter_prepare_cb).
Si se proporcionan las devoluciones de llamada del plugin de salida para decodificar comandos de confirmación en dos fases, entonces
en PREPARE TRANSACTION, los cambios de esa transacción se decodifican, se pasan al plugin de salida y se invoca
la devolución de llamada prepare_cb. Esto difiere de la configuración básica de decodificación donde los cambios
solo se pasan al plugin de salida cuando se confirma una transacción. El inicio de una transacción preparada se indica mediante la
devolución de llamada begin_prepare_cb.
Cuando una transacción preparada se revierte utilizando el ROLLBACK PREPARED, se invoca la devolución de llamada
rollback_prepared_cb y cuando la transacción preparada se confirma utilizando el
COMMIT PREPARED, se invoca la devolución de llamada commit_prepared_cb.
Opcionalmente, el plugin de salida puede definir reglas de filtrado a través de filter_prepare_cb para decodificar
únicamente transacciones específicas en dos fases. Esto se puede lograr mediante la coincidencia de patrones en el parámetro
gid o a través de búsquedas utilizando el parámetro xid.
Los usuarios que deseen decodificar transacciones preparadas deben tener cuidado con los puntos que se mencionan a continuación:
Si la transacción preparada ha bloqueado exclusivamente las tablas del catálogo [del usuario], la decodificación de la preparación puede bloquearse hasta que se confirme la transacción principal.
La solución de replicación lógica que construye la confirmación distribuida en dos fases utilizando esta característica puede
bloquearse (deadlock) si la transacción preparada ha bloqueado exclusivamente las tablas del catálogo [del usuario]. Para evitar
esto, los usuarios deben abstenerse de tener bloqueos en las tablas del catálogo (por ejemplo, el comando LOCK
explícito) en tales transacciones. Consulta la Section 47.8.2 para obtener los detalles.