Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitd81387d

Browse files
committed
walsnd: Don't set waiting_for_ping_response spuriously
Ashutosh Bapat noticed that when logical walsender needs to wait forWAL, and it realizes that it must send a keepalive message towalreceiver to update the sent-LSN, which *does not* request a replyfrom walreceiver, it wrongly sets the flag that it's going to wait forthat reply. That means that any future would-be sender of feedbackmessages ends up not sending a feedback message, because they allbelieve that a reply is expected.With built-in logical replication there's not much harm in this, becauseWalReceiverMain will send a ping-back every wal_receiver_timeout/2anyway; but with other logical replication systems (e.g. pglogical) itcan cause significant pain.This problem was introduced in commit41d5f8a, where therequest-reply flag was changed from true to false to WalSndKeepalive,without at the same time removing the line that setswaiting_for_ping_response.Just removing that line would be a sufficient fix, but it seems betterto shift the responsibility of setting the flag to WalSndKeepaliveitself instead of requiring caller to do it; this is clearly lesserror-prone.Author: Álvaro Herrera <alvherre@alvh.no-ip.org>Reported-by: Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>Backpatch: 9.5 and upDiscussion:https://postgr.es/m/20200806225558.GA22401@alvherre.pgsql
1 parent1ed7b43 commitd81387d

File tree

1 file changed

+16
-14
lines changed

1 file changed

+16
-14
lines changed

‎src/backend/replication/walsender.c‎

Lines changed: 16 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -155,7 +155,7 @@ static XLogRecPtr sendTimeLineValidUpto = InvalidXLogRecPtr;
155155
* How far have we sent WAL already? This is also advertised in
156156
* MyWalSnd->sentPtr. (Actually, this is the next WAL location to send.)
157157
*/
158-
staticXLogRecPtrsentPtr=0;
158+
staticXLogRecPtrsentPtr=InvalidXLogRecPtr;
159159

160160
/* Buffers for constructing outgoing messages and processing reply messages. */
161161
staticStringInfoDataoutput_message;
@@ -1348,16 +1348,15 @@ WalSndWaitForWal(XLogRecPtr loc)
13481348
/*
13491349
* We only send regular messages to the client for full decoded
13501350
* transactions, but a synchronous replication and walsender shutdown
1351-
* possibly are waiting for a later location. So we send pings
1352-
* containing the flush location every now and then.
1351+
* possibly are waiting for a later location. So, before sleeping, we
1352+
* send a ping containing the flush location. If the receiver is
1353+
* otherwise idle, this keepalive will trigger a reply. Processing the
1354+
* reply will update these MyWalSnd locations.
13531355
*/
13541356
if (MyWalSnd->flush<sentPtr&&
13551357
MyWalSnd->write<sentPtr&&
13561358
!waiting_for_ping_response)
1357-
{
13581359
WalSndKeepalive(false);
1359-
waiting_for_ping_response= true;
1360-
}
13611360

13621361
/* check whether we're done */
13631362
if (loc <=RecentFlushPtr)
@@ -2858,10 +2857,7 @@ WalSndDone(WalSndSendDataCallback send_data)
28582857
proc_exit(0);
28592858
}
28602859
if (!waiting_for_ping_response)
2861-
{
28622860
WalSndKeepalive(true);
2863-
waiting_for_ping_response= true;
2864-
}
28652861
}
28662862

28672863
/*
@@ -3357,10 +3353,13 @@ pg_stat_get_wal_senders(PG_FUNCTION_ARGS)
33573353
}
33583354

33593355
/*
3360-
* This function is used to send a keepalive message to standby.
3361-
* If requestReply is set, sets a flag in the message requesting the standby
3362-
* to send a message back to us, for heartbeat purposes.
3363-
*/
3356+
* Send a keepalive message to standby.
3357+
*
3358+
* If requestReply is set, the message requests the other party to send
3359+
* a message back to us, for heartbeat purposes. We also set a flag to
3360+
* let nearby code that we're waiting for that response, to avoid
3361+
* repeated requests.
3362+
*/
33643363
staticvoid
33653364
WalSndKeepalive(boolrequestReply)
33663365
{
@@ -3375,6 +3374,10 @@ WalSndKeepalive(bool requestReply)
33753374

33763375
/* ... and send it wrapped in CopyData */
33773376
pq_putmessage_noblock('d',output_message.data,output_message.len);
3377+
3378+
/* Set local flag */
3379+
if (requestReply)
3380+
waiting_for_ping_response= true;
33783381
}
33793382

33803383
/*
@@ -3405,7 +3408,6 @@ WalSndKeepaliveIfNecessary(void)
34053408
if (last_processing >=ping_time)
34063409
{
34073410
WalSndKeepalive(true);
3408-
waiting_for_ping_response= true;
34093411

34103412
/* Try to flush pending output to the client */
34113413
if (pq_flush_if_writable()!=0)

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp