Hello
I want to return to this discussion, since primary_conninfo is now PGC_SIGHUP (and I hope will not be reverted)
> 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().
So...
We call restore_command only when walreceiver is stopped.
We use restore_command only in startup process - so we have no race condition between processes.
We have some issues here? Or we can just make restore_command reloadable as attached?
regards, Sergei
