1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00

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
This commit is contained in:
Peter Eisentraut
2023-08-29 15:15:54 +02:00
parent f347ec76e2
commit 63956bed7b
10 changed files with 41 additions and 41 deletions

View File

@ -1160,7 +1160,7 @@ pa_send_data(ParallelApplyWorkerInfo *winfo, Size nbytes, const void *data)
* We don't try to send data to parallel worker for 'immediate' mode. This
* is primarily used for testing purposes.
*/
if (unlikely(logical_replication_mode == LOGICAL_REP_MODE_IMMEDIATE))
if (unlikely(debug_logical_replication_streaming == DEBUG_LOGICAL_REP_STREAMING_IMMEDIATE))
return false;
/*

View File

@ -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))
{
/*