diff options
author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2020-08-08 12:31:55 -0400 |
---|---|---|
committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2020-08-08 12:31:55 -0400 |
commit | 85cb4ec509c3a27f1b3b8bcaf23a87a76a5a44d0 (patch) | |
tree | f2db3758d2d56945d9ba5fff048c8cae6c960271 /src/backend/commands/typecmds.c | |
parent | 4f26932296057721d7668ec13cfd6af2bb8410ec (diff) | |
download | postgresql-85cb4ec509c3a27f1b3b8bcaf23a87a76a5a44d0.tar.gz postgresql-85cb4ec509c3a27f1b3b8bcaf23a87a76a5a44d0.zip |
walsnd: Don't set waiting_for_ping_response spuriously
Ashutosh Bapat noticed that when logical walsender needs to wait for
WAL, and it realizes that it must send a keepalive message to
walreceiver to update the sent-LSN, which *does not* request a reply
from walreceiver, it wrongly sets the flag that it's going to wait for
that reply. That means that any future would-be sender of feedback
messages ends up not sending a feedback message, because they all
believe that a reply is expected.
With built-in logical replication there's not much harm in this, because
WalReceiverMain will send a ping-back every wal_receiver_timeout/2
anyway; but with other logical replication systems (e.g. pglogical) it
can cause significant pain.
This problem was introduced in commit 41d5f8ad734, where the
request-reply flag was changed from true to false to WalSndKeepalive,
without at the same time removing the line that sets
waiting_for_ping_response.
Just removing that line would be a sufficient fix, but it seems better
to shift the responsibility of setting the flag to WalSndKeepalive
itself instead of requiring caller to do it; this is clearly less
error-prone.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reported-by: Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>
Backpatch: 9.5 and up
Discussion: https://postgr.es/m/20200806225558.GA22401@alvherre.pgsql
Diffstat (limited to 'src/backend/commands/typecmds.c')
0 files changed, 0 insertions, 0 deletions