On Wed, Sep 14, 2022 at 09:31:04PM +0200, Peter Eisentraut wrote:
> Here is a patch that addresses this.
My intent was to present archive_command as the built-in archive library,
but I can see how this might cause confusion, so this change seems
reasonable to me.
> + <para>
> + It is important that the archive command return zero exit status if and
> + only if it succeeds. Upon getting a zero result,
> + <productname>PostgreSQL</productname> will assume that the file has been
> + successfully archived, and will remove or recycle it. However, a nonzero
> + status tells <productname>PostgreSQL</productname> that the file was not archived;
> + it will try again periodically until it succeeds.
> + </para>
> +
> + <para>
> + When the archive command is terminated by a signal (other than
> + <systemitem>SIGTERM</systemitem> that is used as part of a server
> + shutdown) or an error by the shell with an exit status greater than
> + 125 (such as command not found), the archiver process aborts and gets
> + restarted by the postmaster. In such cases, the failure is
> + not reported in <xref linkend="pg-stat-archiver-view"/>.
> + </para>
This wording is very similar to the existing wording in the archive library
section below it. I think the second paragraph covers the shell command case
explicitly, too. Perhaps these should be combined.
> + <varname>archive_mode</varname> and <varname>archive_command</varname> are
> + separate variables so that <varname>archive_command</varname> can be
> + changed without leaving archiving mode.
I believe this applies to archive_library, too.
> - for segments to complete like <xref linkend="guc-archive-library"/> does.
> + for segments to complete like <xref linkend="guc-archive-command"/> and
> + <xref linkend="guc-archive-library"/> does.
nitpick: s/does/do
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
