Re: Allow some recovery parameters to be changed with reload

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
Date: 2020-03-28 11:20:44
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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().

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

Attachment Content-Type Size
v1_restore_command_reload.patch text/x-diff 1.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Ivan N. Taranov 2020-03-28 12:06:06 Re: [PATCH] postgresql.conf.sample->
Previous Message Peter Eisentraut 2020-03-28 11:13:38 Re: [PATCH] postgresql.conf.sample->