PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 14.6 » Programmation serveur » Décodage logique (Logical Decoding) » Support du Two-phase commit pour le décodage logique

49.10. Support du Two-phase commit pour le décodage logique

Avec les fonctions callbacks simples pour le plugin de sortie (donc begin_cb, change_cb, commit_cb et message_cb), les commandes du two-phase commit comme PREPARE TRANSACTION, COMMIT PREPARED et ROLLBACK PREPARED ne sont pas décodées. Alors que PREPARE TRANSACTION est ignoré, COMMIT PREPARED est décodé comme un COMMIT et ROLLBACK PREPARED est décodé comme un ROLLBACK.

Pour accepter le flux des commandes de la validation en deux phases, un plugin de sortie doit fournir des fonctions callbacks supplémentaires. Il existe plusieurs fonctions callbacks requises pour le two-phase commit (begin_prepare_cb, prepare_cb, commit_prepared_cb, rollback_prepared_cb et stream_prepare_cb) et une fonction callback facultative(filter_prepare_cb).

Si les fonctions callbacks du plugin de sortie sont fournies pour le décodage des commandes de validation en deux phases, alors, sur un PREPARE TRANSACTION, les changements de cette transaction sont décodés, passés au plugin de sortie, et la fonction callback prepare_cb est appelée. Ceci change de la configuration basique de décodage où les changements sont seulement passés au plugin de sortie quand une transaction est validée. Le début d'une transaction préparée est indiqué par la fonction callback begin_prepare_cb.

Quand une transaction préparée est annulée en utilisant ROLLBACK PREPARED, alors la fonction callback rollback_prepared_cb est appelée, et quand la transaction préparée est validée en utilisant COMMIT PREPARED, alors la fonction callback commit_prepared_cb est appelée.

En option, le plugin de sortie peut définir des règles de filtres via filter_prepare_cb pour décoder uniquement les transactions en deux phases. Ceci peut se faire avec la correspondance de motif sur gid ou via des recherches en utilisant xid.

Les utilisateurs qui veulent décoder les transactions préparées doivent faire attention aux points mentionnés ci-dessous :

  • Si la transaction préparée a verrouillé des tables systèmes en mode exclusif, alors le décodage de la préparation peut bloquer jusqu'à la validation de la transaction principale.

  • La solution de réplication logique qui construit une validation en deux phases distribuée en utilisant cette fonctionnalité peut provoquer un deadlock si la transaction préparée a verrouillé en exclusif des tables systèmes. Pour éviter ceci, les utilisateurs doivent éviter d'avoir des verrous sur des tables systèmes (comme une commande LOCK explicite) dans de telles transactions. Voir Section 49.8.2 pour les détails.