aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/arrayfuncs.c
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2020-08-08 12:31:55 -0400
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2020-08-08 12:31:55 -0400
commit1fa6eec974f8f17f8c5fcd54eb33625f9b107050 (patch)
tree4f97da081a4d52c5a0908868903eb60f6e21699d /src/backend/utils/adt/arrayfuncs.c
parent1db9c80f835e436ca3c27bccf43135ebf7e3c62b (diff)
downloadpostgresql-1fa6eec974f8f17f8c5fcd54eb33625f9b107050.tar.gz
postgresql-1fa6eec974f8f17f8c5fcd54eb33625f9b107050.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/utils/adt/arrayfuncs.c')
0 files changed, 0 insertions, 0 deletions