Fix deferred XLogLogicalInfo update after a failed transaction block. Previously, a backend with an assigned XID deferred the XLogLogicalInfo update requested by a procsignal barrier, and we applied it in AbortTransaction() on abort. However, a failed transaction block keeps its XID until ROLLBACK, so a barrier absorbed while idle in that state was deferred, and CleanupTransaction() did not apply it. The next transaction then ran entirely with the stale value. If logical decoding had just been enabled, that transaction's changes were written without logical information and silently skipped by decoding.
Fix by applying the pending update in CleanupTransaction() instead of AbortTransaction(). We call it after resetting the top-level XID because, unlike the commit and prepare paths, CleanupTransaction() isn't always called with interrupts held, so a barrier absorbed before the reset would be deferred again and carried into the next transaction. Patch by Sergei Patiakin, with tests added by me. Oversight in commit 67c20979ce7. Reported-by: Sergei Patiakin <[email protected]> Author: Sergei Patiakin <[email protected]> Reviewed-by: Shlok Kyal <[email protected]> Reviewed-by: Hayato Kuroda <[email protected]> Reviewed-by: Masahiko Sawada <[email protected]> Reviewed-by: Bertrand Drouvot <[email protected]> Discussion: https://postgr.es/m/cane55rapenafaqxlwrvm-nc0y5gkrbfzfvahvyp89ags2sy...@mail.gmail.com Backpatch-through: 19 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a80744949ca065d0e21998344aabaa803c02713d Modified Files -------------- src/backend/access/transam/xact.c | 12 ++++++++++- src/backend/replication/logical/logicalctl.c | 6 +++++- src/test/recovery/t/051_effective_wal_level.pl | 30 ++++++++++++++++++++++++++ 3 files changed, 46 insertions(+), 2 deletions(-)
