Re: Allow some recovery parameters to be changed with reload - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Allow some recovery parameters to be changed with reload
Date
Msg-id 20201127.120545.1039699675559027058.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Allow some recovery parameters to be changed with reload  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Allow some recovery parameters to be changed with reload  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
At Fri, 27 Nov 2020 09:48:25 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in 
> 
> 
> On 2020/11/27 9:30, Kyotaro Horiguchi wrote:
> > At Thu, 26 Nov 2020 22:43:48 +0900, Fujii Masao
> > <masao.fujii@oss.nttdata.com> wrote in
> >>
> >>
> >> On 2020/11/12 4:38, Sergei Kornilov wrote:
> >>> Hello
> >>>
> >>>> Anyway, for now I think that your first patch would be enough, i.e.,
> >>>> just change the context of restore_command to PGC_SIGHUP.
> >>> Glad to hear. Attached a rebased version of the original proposal.
> >>
> >> Thanks for rebasing the patch!
> >>
> >>      This parameter is required for archive recovery,
> >>
> >> I found the above description in config.sgml. I was just wondering
> >> if it should be updated so that the actual specification is described
> >> or not.
> >> The actual spec is that restore_command is required to start archive
> >> recovery, but optional (i.e., the parameter can be reset to an empty)
> >> after archive recovery has started. But this updated version of
> >> description would be rather confusing to users. So I'm now thinking
> >> not to update that.
> >>
> >> Does anyone object to the patch? If no, I'm thinking to commit the
> >> patch.
> > Although I don't object to make the parameter reloadable, I think it
> > needs to be documented that server could stop after reloading if the
> > server failed to execute the new command line.
> 
> You mean that we should document that if restore_command is set to
> improper command mistakenly, archive recovery may fail to restore some
> archived WAL files and finish without replaying those WAL? But isn't
> this true even without applying the patch?

If we set a wrong command in .conf and start the server in recovery
mode, the server immediately stops. It's fine.  If we change
restore_command wrong way on a running server, "pg_ctl reload" stops
the server.  If it is a hot standby, the server stops unexpectedly.

However, after rechecking, I found that recovery_end_command with
wrong content causes server stop at the end of recovery, or at
promotion. And that variable is PGC_SIGHUP.

So I agree not to document that.  Sorry for the noise.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: POC: postgres_fdw insert batching
Next
From: Bharath Rupireddy
Date:
Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module