Re: Allow some recovery parameters to be changed with reload
От | Fujii Masao |
---|---|
Тема | Re: Allow some recovery parameters to be changed with reload |
Дата | |
Msg-id | aab54031-ae9d-3199-2d01-7fb739b69f38@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Allow some recovery parameters to be changed with reload (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Allow some recovery parameters to be changed with reload
|
Список | pgsql-hackers |
On 2020/11/27 12:05, Kyotaro Horiguchi wrote: > 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. OK, so I pushed the patch. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: