v1-0001-Fix-concurrent-abort-for-when-streaming.patch

From e109c0c813b882d4438a40ccbe25903ffbde14a5 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.b.smith@fujitsu.com>
Date: Mon, 26 Apr 2021 10:57:47 +1000
Subject: [PATCH v1] Fix concurrent abort for when streaming.

When a concurrent-abort was detected ReorderBufferPrepare is sending "prepare".
But when using streaming there was already a "stream_prepare" sent for same tx.

The double sending of prepares would cause a GID clash detected in worker.c, giving
errors like: ERROR:  transaction identifier "pg_gid_16403_596" is already in use

This patch prevents the double-sending of prepares when streaming.
---
 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 341bef5..21b5f11 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 streaming_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);
 }
 
-- 
1.8.3.1