From f25a4584c6f56f3407f8f8734c78f2a87e4b77e8 Mon Sep 17 00:00:00 2001 From: Amit Kapila Date: Mon, 26 Apr 2021 11:27:44 +0530 Subject: [PATCH] Avoid sending prepare multiple times while decoding. We send the prepare for the concurrently aborted xacts so that later when rollback prepared is decoded and sent, the downstream should be able to rollback such a xact. For 'streaming' case (when we send changes for in-progress transactions), we were sending prepare twice when concurrent abort was detected. Author: Peter Smith Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/f82133c6-6055-b400-7922-97dae9f2b50b@enterprisedb.com --- src/backend/replication/logical/reorderbuffer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c index 5f8907bb74..c27f710053 100644 --- a/src/backend/replication/logical/reorderbuffer.c +++ b/src/backend/replication/logical/reorderbuffer.c @@ -2690,8 +2690,11 @@ ReorderBufferPrepare(ReorderBuffer *rb, TransactionId xid, * We send the prepare for the concurrently aborted xacts so that later * when rollback prepared is decoded and sent, the downstream should be * able to rollback such a xact. See comments atop DecodePrepare. + * + * Note, for the concurrent_abort + streaming case a stream_prepare was + * already sent within the ReorderBufferReplay call above. */ - if (txn->concurrent_abort) + if (txn->concurrent_abort && !rbtxn_is_streamed(txn)) rb->prepare(rb, txn, txn->final_lsn); }