Re: Questionable ping logic in LogicalRepApplyLoop
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Petr Jelinek <petr@2ndquadrant.com>
Date: 2020-09-04T20:41:47Z
Lists: pgsql-hackers
On 2020-Sep-04, Tom Lane wrote: > While playing around with clang's scan-build I noticed this warning: > > worker.c:2281:7: warning: Value stored to 'ping_sent' is never read > ping_sent = true; > ^ ~~~~ > > At first I thought it was a harmless unnecessary update, but looking > closer I wonder whether it isn't telling us there is a logic bug here. > Specifically, I wonder why the "ping_sent" variable is local to the > loop starting at line 2084, rather than having the same lifespan as > "last_recv_timestamp". Do we really want to forget that we sent a > ping anytime we have to wait for more data? Ah ... maybe this bug is the reason why the bug fixed by 470687b4a5bb did not affect logical replication. > In short, we could remove the ping_sent variable entirely without > changing this code's behavior. I'm not 100% sure what semantics > it's trying to achieve, but I don't think it's achieving them. I imagine that moving the variable one block-scope outwards (together with last_recv_timestamp) is what was intended. ... oh look! commit 3f60f690fac1 moved last_recv_timestamp without realizing that ping_sent had to get the same treatment. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Fix over-eager ping'ing in logical replication receiver.
- 9b81a30f924c 13.0 landed
- c8746f999ea2 14.0 landed
- 9b8a8516ed2e 10.15 landed
- 9b47ee6e7cba 12.5 landed
- 7156a0eac3af 11.10 landed
-
Fix timeout handling in logical replication worker
- 3f60f690fac1 13.0 cited