From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | talk to ben <blo(dot)talkto(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: archive_command / pg_stat_archiver & documentation |
Date: | 2021-02-24 13:52:06 |
Message-ID: | CAOBaU_akoTr=CbRjRR9DfMPGYY5KLGn-45vpkOXy9MSa8uwcoA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
> 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!
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-02-24 14:11:36 | Re: Parallel INSERT (INTO ... SELECT ...) |
Previous Message | Amit Kapila | 2021-02-24 13:19:46 | Re: Parallel INSERT (INTO ... SELECT ...) |