Hi, On 2019-02-08 09:19:31 +0900, Michael Paquier wrote: > On Thu, Feb 07, 2019 at 11:06:27PM +0100, Peter Eisentraut wrote: > > Probably right. I figured it would be useful to see what the outcome is > > with primary_conninfo, so they can be treated similarly. > > The interactions with waiting for WAL to be available and the WAL > receiver stresses me a bit for restore_command, as you could finish > with the startup process switching to use restore_command with a WAL > receiver still working behind and overwriting partially the recovered > segment, which could lead to corruption. We should be *very* careful > about that.
I'm not clear on the precise mechanics you're imagining here, could you expand a bit? We kill the walreceiver when switching from receiver to restore command, and wait for it to acknowledge that, no? C.F. ShutdownWalRcv() call in the lastSourceFailed branch of WaitForWALToBecomeAvailable(). Greetings, Andres Freund
