> > Patch 0001 looks OK for me. > > Regarding patch 0002. Changes made for GetCurrentLSNForWaitType() > > looks reliable for me. PerformWalRecovery() sets replayed positions > > before starting recovery, and in turn before standby can accept > > connections. So, changes to WalReceiverMain() don't look necessary to > > me. > > Yeah, GetCurrentLSNForWaitType seems to be the right place to place > the fix. Please see the attached patch 2. > > I also noticed another relevent problem: > > During pure archive recovery (no walreceiver), a backend that issues > 'WAIT FOR LSN ... MODE 'standby_write' with a target ahead of the > current replay position will sleep forever; the startup process > replays past the target but only wakes 'STANDBY_REPLAY' waiters. > > This also affects mixed scenarios: the walreceiver may lag behind > replay (e.g., archive restore has delivered WAL faster than > streaming), so a 'standby_write' waiter could be waiting on WAL that > replay has already consumed. > > I will write a patch to address this soon. >
Here is the patch. -- Best, Xuneng
v1-0003-Wake-standby_write-standby_flush-waiters-from-the.patch
Description: Binary data
