Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 4778826

Browse files
author
Amit Kapila
committed
Ensure to send a prepare after we detect concurrent abort during decoding.
It is possible that while decoding a prepared transaction, it gets aborted concurrently via a ROLLBACK PREPARED command. In that case, we were skipping all the changes and directly sending Rollback Prepared when we find the same in WAL. However, the downstream has no idea of the GID of such a transaction. So, ensure to send prepare even when a concurrent abort is detected. Author: Ajin Cherian Reviewed-by: Markus Wanner, Amit Kapila Discussion: https://postgr.es/m/f82133c6-6055-b400-7922-97dae9f2b50b@enterprisedb.com
1 parent 0d1a334 commit 4778826

File tree

2 files changed

+17
-6
lines changed

2 files changed

+17
-6
lines changed

doc/src/sgml/logicaldecoding.sgml

+9-6
Original file line numberDiff line numberDiff line change
@@ -545,12 +545,15 @@ CREATE TABLE another_catalog_table(data text) WITH (user_catalog_table = true);
545545
executed within that transaction. A transaction that is prepared for
546546
a two-phase commit using <command>PREPARE TRANSACTION</command> will
547547
also be decoded if the output plugin callbacks needed for decoding
548-
them are provided. It is possible that the current transaction which
549-
is being decoded is aborted concurrently via a <command>ROLLBACK PREPARED</command>
550-
command. In that case, the logical decoding of this transaction will
551-
be aborted too. We will skip all the changes of such a transaction once
552-
the abort is detected and abort the transaction when we read WAL for
553-
<command>ROLLBACK PREPARED</command>.
548+
them are provided. It is possible that the current prepared transaction
549+
which is being decoded is aborted concurrently via a
550+
<command>ROLLBACK PREPARED</command> command. In that case, the logical
551+
decoding of this transaction will be aborted too. All the changes of such
552+
a transaction are skipped once the abort is detected and the
553+
<function>prepare_cb</function> callback is invoked. Thus even in case of
554+
a concurrent abort, enough information is provided to the output plugin
555+
for it to properly deal with <command>ROLLBACK PREPARED</command> once
556+
that is decoded.
554557
</para>
555558

556559
<note>

src/backend/replication/logical/reorderbuffer.c

+8
Original file line numberDiff line numberDiff line change
@@ -2664,6 +2664,14 @@ ReorderBufferPrepare(ReorderBuffer *rb, TransactionId xid,
26642664

26652665
ReorderBufferReplay(txn, rb, xid, txn->final_lsn, txn->end_lsn,
26662666
txn->commit_time, txn->origin_id, txn->origin_lsn);
2667+
2668+
/*
2669+
* We send the prepare for the concurrently aborted xacts so that later
2670+
* when rollback prepared is decoded and sent, the downstream should be
2671+
* able to rollback such a xact. See comments atop DecodePrepare.
2672+
*/
2673+
if (txn->concurrent_abort)
2674+
rb->prepare(rb, txn, txn->final_lsn);
26672675
}
26682676

26692677
/*

0 commit comments

Comments
 (0)