Re: Blank archive_command

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Blank archive_command
Date: 2022-01-17 15:52:59
Message-ID: CALj2ACVBVhFGDHdKtW4uY4+YqsPgbqU2a+L-U-PgHFWr+7M3VQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 17, 2022 at 9:05 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> +1 to not create any GUC setting dependencies. Let's leave the
> responsibility of setting appropriate archive_command to the archiving
> handlers outside postgres. FWIW, having a note in the archive_command
> GUC definition in the docs might help to some extent.

On further search, the documentation says the following which is enough IMO:

This parameter can only be set in the postgresql.conf file or on the
server command line. It is ignored unless archive_mode was enabled at
server start. If archive_command is an empty string (the default)
while archive_mode is enabled, WAL archiving is temporarily disabled,
but the server continues to accumulate WAL segment files in the
expectation that a command will soon be provided. Setting
archive_command to a command that does nothing but return true, e.g.,
/bin/true (REM on Windows), effectively disables archiving, but also
breaks the chain of WAL files needed for archive recovery, so it
should only be used in unusual circumstances.

https://www.postgresql.org/docs/devel/runtime-config-wal.html#GUC-ARCHIVE-COMMAND

Regards,
Bharath Rupireddy.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-01-17 16:16:36 Re: Add Boolean node
Previous Message Thom Brown 2022-01-17 15:45:08 Re: Blank archive_command