Re: archive_command / pg_stat_archiver & documentation

Le mer. 24 févr. 2021 à 14:52, Julien Rouhaud <rjuju123(at)gmail(dot)com> a écrit :

> Hi,
>
> On Wed, Feb 24, 2021 at 8:21 PM talk to ben <blo(dot)talkto(at)gmail(dot)com> wrote:
> >
> > The documentation describes how a return code > 125 on the
> restore_command would prevent the server from starting [1] :
> >
> > "
> > It is important that the command return nonzero exit status on failure.
> The command will be called requesting files that are not present in the
> archive; it must return nonzero when so asked. This is not an error
> condition. An exception is that if the command was terminated by a signal
> (other than SIGTERM, which is used as part of a database server shutdown)
> or an error by the shell (such as command not found), then recovery will
> abort and the server will not start up.
> > "
> >
> > But, I dont see such a note on the archive_command side of thing. [2]
> >
> > It could happend in case the archive command is not checked beforehand
> or if the archive command becomes unavailable while PostgreSQL is running.
> rsync can also return 255 in some cases (bad ssh configuration or typos).
> In this case a fatal error is emitted, the archiver stops and is restarted
> by the postmaster.
> >
> > The view pg_stat_archiver is also not updated in this case. Is it on
> purpose ? It could be problematic if someone uses it to check the archiver
> process health.
>
> That's on purpose, see for instance that discussion:
> https://www.postgresql.org/message-id/flat/55731BB8.1050605%40dalibo.com
>

Thanks for pointing that out, I should have checked.

> > Should we document this ? (I can make a patch)
>
> I thought that this behavior was documented, especially for the lack
> of update of pg_stat_archiver. If it's not the case then we should
> definitely fix that!
>

I tried to do it in the attached patch.
Building the doc worked fine on my computer.