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

diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c
index 5f8907bb743b5618edc7730a65543f1168aec15c..c27f710053474061904ad9df00c2af7848e14c0e 100644 (file)
--- 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);
 }