|From:||Sergei Kornilov <sk(at)zsrv(dot)org>|
|To:||Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Allow some recovery parameters to be changed with reload|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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?
|Next Message||Ivan N. Taranov||2020-03-28 12:06:06||Re: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in|
|Previous Message||Peter Eisentraut||2020-03-28 11:13:38||Re: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in|