On 2020/11/27 12:05, Kyotaro Horiguchi wrote:
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.

OK, so I pushed the patch. Thanks!

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION


Reply via email to