Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 4216858

Browse files
committed
When WalSndCaughtUp, sleep only in WalSndWaitForWal().
Before sleeping, WalSndWaitForWal() sends a keepalive if MyWalSnd->write < sentPtr. That is important in logical replication. When the latest physical LSN yields no logical replication messages (a common case), that keepalive elicits a reply, and processing the reply updates pg_stat_replication.replay_lsn. WalSndLoop() lacks that; when WalSndLoop() slept, replay_lsn advancement could stall until wal_receiver_status_interval elapsed. This sometimes stalled src/test/subscription/t/001_rep_changes.pl for up to 10s. Discussion: https://postgr.es/m/20200406063649.GA3738151@rfd.leadboat.com
1 parent 969f9d0 commit 4216858

File tree

1 file changed

+8
-13
lines changed

1 file changed

+8
-13
lines changed

src/backend/replication/walsender.c

Lines changed: 8 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1428,8 +1428,10 @@ WalSndWaitForWal(XLogRecPtr loc)
14281428
/*
14291429
* We only send regular messages to the client for full decoded
14301430
* transactions, but a synchronous replication and walsender shutdown
1431-
* possibly are waiting for a later location. So we send pings
1432-
* containing the flush location every now and then.
1431+
* possibly are waiting for a later location. So, before sleeping, we
1432+
* send a ping containing the flush location. If the receiver is
1433+
* otherwise idle, this keepalive will trigger a reply. Processing the
1434+
* reply will update these MyWalSnd locations.
14331435
*/
14341436
if (MyWalSnd->flush < sentPtr &&
14351437
MyWalSnd->write < sentPtr &&
@@ -2314,30 +2316,23 @@ WalSndLoop(WalSndSendDataCallback send_data)
23142316
WalSndKeepaliveIfNecessary();
23152317

23162318
/*
2317-
* We don't block if not caught up, unless there is unsent data
2318-
* pending in which case we'd better block until the socket is
2319-
* write-ready. This test is only needed for the case where the
2320-
* send_data callback handled a subset of the available data but then
2321-
* pq_flush_if_writable flushed it all --- we should immediately try
2322-
* to send more.
2319+
* Block if we have unsent data. Let WalSndWaitForWal() handle any
2320+
* other blocking; idle receivers need its additional actions.
23232321
*/
2324-
if ((WalSndCaughtUp && !streamingDoneSending) || pq_is_send_pending())
2322+
if (pq_is_send_pending())
23252323
{
23262324
long sleeptime;
23272325
int wakeEvents;
23282326

23292327
wakeEvents = WL_LATCH_SET | WL_EXIT_ON_PM_DEATH | WL_TIMEOUT |
2330-
WL_SOCKET_READABLE;
2328+
WL_SOCKET_READABLE | WL_SOCKET_WRITEABLE;
23312329

23322330
/*
23332331
* Use fresh timestamp, not last_processing, to reduce the chance
23342332
* of reaching wal_sender_timeout before sending a keepalive.
23352333
*/
23362334
sleeptime = WalSndComputeSleeptime(GetCurrentTimestamp());
23372335

2338-
if (pq_is_send_pending())
2339-
wakeEvents |= WL_SOCKET_WRITEABLE;
2340-
23412336
/* Sleep until something happens or we time out */
23422337
(void) WaitLatchOrSocket(MyLatch, wakeEvents,
23432338
MyProcPort->sock, sleeptime,

0 commit comments

Comments
 (0)