> > 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
