At Fri, 27 Nov 2020 09:48:25 +0900, Fujii Masao <masao.fu...@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.fu...@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
