8000 Remove wal_sender_delay GUC, because it's no longer useful. · postgrespro/postgres_cluster@cff7513 · GitHub
[go: up one dir, main page]
Skip to content

Commit cff7513

Browse files
tglsfdctglsfdc
committed
Remove wal_sender_delay GUC, because it's no longer useful.
The latch infrastructure is now capable of detecting all cases where the walsender loop needs to wake up, so there is no reason to have an arbitrary timeout. Also, modify the walsender loop logic to follow the standard pattern of ResetLatch, test for work to do, WaitLatch. The previous coding was both hard to follow and buggy: it would sometimes busy-loop despite having nothing available to do, eg between receipt of a signal and the next time it was caught up with new WAL, and it also had interesting choices like deciding to update to WALSNDSTATE_STREAMING on the strength of information known to be obsolete.
1 parent 79b2ee2 commit cff7513

File tree

5 files changed

+70
-104
lines changed

5 files changed

+70
-104
lines changed

‎doc/src/sgml/config.sgml‎

Lines changed: 0 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -2008,29 +2008,6 @@ SET ENABLE_SEQSCAN TO OFF;
20082008
</para>
20092009
</listitem>
20102010
</varlistentry>
2011-
<varlistentry id="guc-wal-sender-delay" xreflabel="wal_sender_delay">
2012-
<term><varname>wal_sender_delay</varname> (<type>integer</type>)</term>
2013-
<indexterm>
2014-
<primary><varname>wal_sender_delay</> configuration parameter</primary>
2015-
</indexterm>
2016-
<listitem>
2017-
<para>
2018-
Specifies the delay between activity rounds for WAL sender processes.
2019-
In each round the WAL sender sends any WAL accumulated since the last
2020-
round to the standby server. It then sleeps for
2021-
<varname>wal_sender_delay</> milliseconds, and repeats. The sleep
2022-
is interrupted by transaction commit, so the effects of a committed
2023-
transaction are sent to standby servers as soon as the commit
2024-
happens, regardless of this setting. The default value is one second
2025-
(<literal>1s</>).
2026-
Note that on many systems, the effective resolution of sleep delays is
2027-
10 milliseconds; setting <varname>wal_sender_delay</> to a value that
2028-
is not a multiple of 10 might have the same results as setting it to
2029-
the next higher multiple of 10. This parameter can only be set in the
2030-
<filename>postgresql.conf</> file or on the server command line.
2031-
</para>
2032-
</listitem>
2033-
</varlistentry>
20342011

20352012
<varlistentry id="guc-wal-keep-segments" xreflabel="wal_keep_segments">
20362013
<term><varname>wal_keep_segments</varname> (<type>integer</type>)</term>

‎src/backend/replication/walsender.c‎

Lines changed: 70 additions & 68 deletions
Original file line numberDiff line numberDiff line change
@@ -75,7 +75,6 @@ bool am_cascading_walsender = false; /* Am I cascading WAL to another standby ?
7575

7676
/* User-settable parameters for walsender */
7777
int max_wal_senders = 0; /* the maximum number of concurrent walsenders */
78-
int WalSndDelay = 1000; /* max sleep time between some actions */
7978
int replication_timeout = 60 * 1000; /* maximum time to send one
8079
* WAL data message */
8180

@@ -475,7 +474,7 @@ ProcessRepliesIfAny(void)
475474
{
476475
unsigned char firstchar;
477476
int r;
478-
int received = false;
477+
bool received = false;
479478

480479
for (;;)
481480
{
@@ -709,6 +708,9 @@ WalSndLoop(void)
709708
/* Loop forever, unless we get an error */
710709
for (;;)
711710
{
711+
/* Clear any already-pending wakeups */
712+
ResetLatch(&MyWalSnd->latch);
713+
712714
/*
713715
* Emergency bailout if postmaster has died. This is to avoid the
714716
* necessity for manual cleanup of all postmaster children.
@@ -727,94 +729,112 @@ WalSndLoop(void)
727729
/* Normal exit from the walsender is here */
728730
if (walsender_shutdown_requested)
729731
{
730-
/* Inform the standby that XLOG streaming was done */
732+
/* Inform the standby that XLOG streaming is done */
731733
pq_puttextmessage('C', "COPY 0");
732734
pq_flush();
733735

734736
proc_exit(0);
735737
}
736738

739+
/* Check for input from the client */
740+
ProcessRepliesIfAny();
741+
737742
/*
738743
* If we don't have any pending data in the output buffer, try to send
739-
* some more.
744+
* some more. If there is some, we don't bother to call XLogSend
745+
* again until we've flushed it ... but we'd better assume we are not
746+
* caught up.
740747
*/
741748
if (!pq_is_send_pending())
742-
{
743749
XLogSend(output_message, &caughtup);
750+
else
751+
caughtup = false;
744752

753+
/* Try to flush pending output to the client */
754+
if (pq_flush_if_writable() != 0)
755+
break;
756+
757+
/* If nothing remains to be sent right now ... */
758+
if (caughtup && !pq_is_send_pending())
759+
{
745760
/*
746-
* Even if we wrote all the WAL that was available when we started
747-
* sending, more might have arrived while we were sending this
748-
* batch. We had the latch set while sending, so we have not
749-
* received any signals from that time. Let's arm the latch again,
750-
* and after that check that we're still up-to-date.
761+
* If we're in catchup state, move to streaming. This is an
762+
* important state change for users to know about, since before
763+
* this point data loss might occur if the primary dies and we
764+
* need to failover to the standby. The state change is also
765+
* important for synchronous replication, since commits that
766+
* started to wait at that point might wait for some time.
751767
*/
752-
if (caughtup && !pq_is_send_pending())
768+
if (MyWalSnd->state == WALSNDSTATE_CATCHUP)
753769
{
754-
ResetLatch(&MyWalSnd->latch);
770+
ereport(DEBUG1,
771+
(errmsg("standby \"%s\" has now caught up with primary",
772+
application_name)));
773+
WalSndSetState(WALSNDSTATE_STREAMING);
774+
}
755775

776+
/*
777+
* When SIGUSR2 arrives, we send any outstanding logs up to the
778+
* shutdown checkpoint record (i.e., the latest record) and exit.
779+
* This may be a normal termination at shutdown, or a promotion,
780+
* the walsender is not sure which.
781+
*/
782+
if (walsender_ready_to_stop)
783+
{
784+
/* ... let's just be real sure we're caught up ... */
756785
XLogSend(output_message, &caughtup);
786+
if (caughtup && !pq_is_send_pending())
787+
{
788+
walsender_shutdown_requested = true;
789+
continue; /* don't want to wait more */
790+
}
757791
}
758792
}
759793

760-
/* Flush pending output to the client */
761-
if (pq_flush_if_writable() != 0)
762-
break;
763-
764794
/*
765-
* When SIGUSR2 arrives, we send any outstanding logs up to the
766-
* shutdown checkpoint record (i.e., the latest record) and exit.
767-
* This may be a normal termination at shutdown, or a promotion,
768-
* the walsender is not sure which.
795+
* We don't block if not caught up, unless there is unsent data
796+
* pending in which case we'd better block until the socket is
797+
* write-ready. This test is only needed for the case where XLogSend
798+
* loaded a subset of the available data but then pq_flush_if_writable
799+
* flushed it all --- we should immediately try to send more.
769800
*/
770-
if (walsender_ready_to_stop && !pq_is_send_pending())
771-
{
772-
XLogSend(output_message, &caughtup);
773-
ProcessRepliesIfAny();
774-
if (caughtup && !pq_is_send_pending())
775-
walsender_shutdown_requested = true;
776-
}
777-
778-
if ((caughtup || pq_is_send_pending()) &&
779-
!got_SIGHUP &&
780-
!walsender_shutdown_requested)
801+
if (caughtup || pq_is_send_pending())
781802
{
782803
TimestampTz finish_time = 0;
783-
long sleeptime;
804+
long sleeptime = -1;
784805
int wakeEvents;
785806

786-
/* Reschedule replication timeout */
807+
wakeEvents = WL_LATCH_SET | WL_POSTMASTER_DEATH |
808+
WL_SOCKET_READABLE;
809+
if (pq_is_send_pending())
810+
wakeEvents |= WL_SOCKET_WRITEABLE;
811+
812+
/* Determine time until replication timeout */
787813
if (replication_timeout > 0)
788814
{
789815
long secs;
790816
int usecs;
791817

792818
finish_time = TimestampTzPlusMilliseconds(last_reply_timestamp,
793-
replication_timeout);
819+
replication_timeout);
794820
TimestampDifference(GetCurrentTimestamp(),
795821
finish_time, &secs, &usecs);
796822
sleeptime = secs * 1000 + usecs / 1000;
797-
if (WalSndDelay < sleeptime)
798-
sleeptime = WalSndDelay;
799-
}
800-
else
801-
{
802-
/*
803-
* XXX: Without timeout, we don't really need the periodic
804-
* wakeups anymore, WaitLatchOrSocket should reliably wake up
805-
* as soon as something interesting happens.
806-
*/
807-
sleeptime = WalSndDelay;
823+
/* Avoid Assert in WaitLatchOrSocket if timeout is past */
824+
if (sleeptime < 0)
825+
sleeptime = 0;
826+
wakeEvents |= WL_TIMEOUT;
808827
}
809828

810-
/* Sleep */
811-
wakeEvents = WL_LATCH_SET | WL_SOCKET_READABLE | WL_TIMEOUT;
812-
if (pq_is_send_pending())
813-
wakeEvents |= WL_SOCKET_WRITEABLE;
829+
/* Sleep until something happens or replication timeout */
814830
WaitLatchOrSocket(&MyWalSnd->latch, wakeEvents,
815831
MyProcPort->sock, sleeptime);
816832

817-
/* Check for replication timeout */
833+
/*
834+
* Check for replication timeout. Note we ignore the corner case
835+
* possibility that the client replied just as we reached the
836+
* timeout ... he's supposed to reply *before* that.
837+
*/
818838
if (replication_timeout > 0 &&
819839
GetCurrentTimestamp() >= finish_time)
820840
{
@@ -828,24 +848,6 @@ WalSndLoop(void)
828848
break;
829849
}
830850
}
831-
832-
/*
833-
* If we're in catchup state, see if its time to move to streaming.
834-
* This is an important state change for users, since before this
835-
* point data loss might occur if the primary dies and we need to
836-
* failover to the standby. The state change is also important for
837-
* synchronous replication, since commits that started to wait at that
838-
* point might wait for some time.
839-
*/
840-
if (MyWalSnd->state == WALSNDSTATE_CATCHUP && caughtup)
841-
{
842-
ereport(DEBUG1,
843-
(errmsg("standby \"%s\" has now caught up with primary",
844-
application_name)));
845-
WalSndSetState(WALSNDSTATE_STREAMING);
846-
}
847-
848-
ProcessRepliesIfAny();
849851
}
850852

851853
/*

‎src/backend/utils/misc/guc.c‎

Lines changed: 0 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1997,17 +1997,6 @@ static struct config_int ConfigureNamesInt[] =
19971997
NULL, NULL, NULL
19981998
},
19991999

2000-
{
2001-
{"wal_sender_delay", PGC_SIGHUP, REPLICATION_SENDING,
2002-
gettext_noop("WAL sender sleep time between WAL replications."),
2003-
NULL,
2004-
GUC_UNIT_MS
2005-
},
2006-
&WalSndDelay,
2007-
1000, 1, 10000,
2008-
NULL, NULL, NULL
2009-
},
2010-
20112000
{
20122001
{"replication_timeout", PGC_SIGHUP, REPLICATION_SENDING,
20132002
gettext_noop("Sets the maximum time to wait for WAL replication."),

‎src/backend/utils/misc/postgresql.conf.sample‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -200,7 +200,6 @@
200200

201201
#max_wal_senders = 0 # max number of walsender processes
202202
# (change requires restart)
203-
#wal_sender_delay = 1s # walsender cycle time, 1-10000 milliseconds
204203
#wal_keep_segments = 0 # in logfile segments, 16MB each; 0 disables
205204
#replication_timeout = 60s # in milliseconds; 0 disables
206205

‎src/include/replication/walsender.h‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -98,7 +98,6 @@ extern volatile sig_atomic_t walsender_shutdown_requested;
9898
extern volatile sig_atomic_t walsender_ready_to_stop;
9999

100100
/* user-settable parameters */
101-
extern int WalSndDelay;
102101
extern int max_wal_senders;
103102
extern int replication_timeout;
104103

0 commit comments

Comments
 (0)
0