diff options
| author | Andres Freund <andres@anarazel.de> | 2016-04-28 22:09:48 -0700 |
|---|---|---|
| committer | Andres Freund <andres@anarazel.de> | 2016-04-28 22:11:18 -0700 |
| commit | 2e1b4adf39178416740efba975757e413a9fb3f9 (patch) | |
| tree | 224c684ce6459a5442563a24c2fa51dfbd77f9fb /src | |
| parent | 94a16531b37628de456e082ee0d60e309607e9dd (diff) | |
| download | postgresql-2e1b4adf39178416740efba975757e413a9fb3f9.tar.gz postgresql-2e1b4adf39178416740efba975757e413a9fb3f9.zip | |
Remember asking for feedback during walsender shutdown.
Since 5a991ef8 we're explicitly asking for feedback from the receiving
side when shutting down walsender, if there's not yet replicated
data.
Unfortunately we didn't remember (i.e. set waiting_for_ping_response to
true) having asked for feedback, leading to scenarios in which replies
were requested at a high frequency.
I can't reproduce this problem on my laptop, I think that's because the
problem requires a significant TCP window to manifest due to the
!pq_is_send_pending() condition. But since this clearly is a bug, let's
fix it. There's quite possibly more wrong than just this though.
While fiddling with WalSndDone(), I rewrote a hard to understand comment
about looking at the flush vs. the write position.
Reported-By: Nick Cleaton, Magnus Hagander
Author: Nick Cleaton
Discussion: CAFgz3kus=rC_avEgBV=+hRK5HYJ8vXskJRh8yEAbahJGTzF2VQ@mail.gmail.com
CABUevExsjROqDcD0A2rnJ6HK6FuKGyewJr3PL12pw85BHFGS2Q@mail.gmail.com
Backpatch: 9.4, were 5a991ef8 introduced the use of feedback messages
during shutdown.
Diffstat (limited to 'src')
| -rw-r--r-- | src/backend/replication/walsender.c | 12 |
1 files changed, 8 insertions, 4 deletions
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c index 6683b6fb475..395f8999d3b 100644 --- a/src/backend/replication/walsender.c +++ b/src/backend/replication/walsender.c @@ -2486,13 +2486,14 @@ WalSndDone(WalSndSendDataCallback send_data) send_data(); /* - * Check a write location to see whether all the WAL have successfully - * been replicated if this walsender is connecting to a standby such as - * pg_receivexlog which always returns an invalid flush location. - * Otherwise, check a flush location. + * To figure out whether all WAL has successfully been replicated, check + * flush location if valid, write otherwise. Tools like pg_receivexlog + * will usually (unless in synchronous mode) return an invalid flush + * location. */ replicatedPtr = XLogRecPtrIsInvalid(MyWalSnd->flush) ? MyWalSnd->write : MyWalSnd->flush; + if (WalSndCaughtUp && sentPtr == replicatedPtr && !pq_is_send_pending()) { @@ -2503,7 +2504,10 @@ WalSndDone(WalSndSendDataCallback send_data) proc_exit(0); } if (!waiting_for_ping_response) + { WalSndKeepalive(true); + waiting_for_ping_response = true; + } } /* |