Rename logical_replication_mode to debug_logical_replication_streaming

The logical_replication_mode GUC is intended for testing and debugging
purposes, but its current name may be misleading and encourage users to make
unnecessary changes.

To avoid confusion, renaming the GUC to a less misleading name
debug_logical_replication_streaming that casual users are less likely to mistakenly
assume needs to be modified in a regular logical replication setup.

Author: Hou Zhijie <houzj.fnst@cn.fujitsu.com>
Reviewed-by: Peter Smith <smithpb2250@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/d672d774-c44b-6fec-f993-793e744f169a%40eisentraut.org

1 files changed, 15 insertions, 15 deletions

diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c
index 87a4d2a24b7..0dab0bb64e8 100644
--- a/src/backend/replication/logical/reorderbuffer.c
+++ b/src/backend/replication/logical/reorderbuffer.c
@@ -210,7 +210,7 @@ int			logical_decoding_work_mem;
 static const Size max_changes_in_memory = 4096; /* XXX for restore only */
 
 /* GUC variable */
-int			logical_replication_mode = LOGICAL_REP_MODE_BUFFERED;
+int			debug_logical_replication_streaming = DEBUG_LOGICAL_REP_STREAMING_BUFFERED;
 
 /* ---------------------------------------
  * primary reorderbuffer support routines
@@ -3566,8 +3566,8 @@ ReorderBufferLargestStreamableTopTXN(ReorderBuffer *rb)
  * pick the largest (sub)transaction at-a-time to evict and spill its changes to
  * disk or send to the output plugin until we reach under the memory limit.
  *
- * If logical_replication_mode is set to "immediate", stream or serialize the
- * changes immediately.
+ * If debug_logical_replication_streaming is set to "immediate", stream or
+ * serialize the changes immediately.
  *
  * XXX At this point we select the transactions until we reach under the memory
  * limit, but we might also adapt a more elaborate eviction strategy - for example
@@ -3580,25 +3580,25 @@ ReorderBufferCheckMemoryLimit(ReorderBuffer *rb)
 	ReorderBufferTXN *txn;
 
 	/*
-	 * Bail out if logical_replication_mode is buffered and we haven't
-	 * exceeded the memory limit.
+	 * Bail out if debug_logical_replication_streaming is buffered and we
+	 * haven't exceeded the memory limit.
 	 */
-	if (logical_replication_mode == LOGICAL_REP_MODE_BUFFERED &&
+	if (debug_logical_replication_streaming == DEBUG_LOGICAL_REP_STREAMING_BUFFERED &&
 		rb->size < logical_decoding_work_mem * 1024L)
 		return;
 
 	/*
-	 * If logical_replication_mode is immediate, loop until there's no change.
-	 * Otherwise, loop until we reach under the memory limit. One might think
-	 * that just by evicting the largest (sub)transaction we will come under
-	 * the memory limit based on assumption that the selected transaction is
-	 * at least as large as the most recent change (which caused us to go over
-	 * the memory limit). However, that is not true because a user can reduce
-	 * the logical_decoding_work_mem to a smaller value before the most recent
-	 * change.
+	 * If debug_logical_replication_streaming is immediate, loop until there's
+	 * no change. Otherwise, loop until we reach under the memory limit. One
+	 * might think that just by evicting the largest (sub)transaction we will
+	 * come under the memory limit based on assumption that the selected
+	 * transaction is at least as large as the most recent change (which
+	 * caused us to go over the memory limit). However, that is not true
+	 * because a user can reduce the logical_decoding_work_mem to a smaller
+	 * value before the most recent change.
 	 */
 	while (rb->size >= logical_decoding_work_mem * 1024L ||
-		   (logical_replication_mode == LOGICAL_REP_MODE_IMMEDIATE &&
+		   (debug_logical_replication_streaming == DEBUG_LOGICAL_REP_STREAMING_IMMEDIATE &&
 			rb->size > 0))
 	{
 		/*