Thread: Ambiguity in restore_command for recovery.conf

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/10/static/archive-recovery-settings.html
Description:

Documentation for restore_command in recovery.conf only says, "This
parameter is required for archive recovery, but optional for streaming
replication," but it doesn't say specifically when the restore_command
string will be used and why. My guess is that as long as the WAL files are
still available on the master (primary) host, the recovery will fetch them
via the replication slot, but if a WAL is missing on the primary, only then
will the restore_command be used. But this isn't explicitly stated. It could
be that the restore_command is always used, even if the WAL file is still
available on the primary.

On Tue, Sep 18, 2018 at 04:10:17PM +0000, PG Doc comments form wrote:
> Documentation for restore_command in recovery.conf only says, "This
> parameter is required for archive recovery, but optional for streaming
> replication," but it doesn't say specifically when the restore_command
> string will be used and why. My guess is that as long as the WAL files
> are still available on the master (primary) host, the recovery will
> fetch them via the replication slot, but if a WAL is missing on the
> primary, only then will the restore_command be used. But this isn't
> explicitly stated. It could be that the restore_command is always
> used, even if the WAL file is still available on the primary.

The logic around the source used to fetch WAL segments is defined in
WaitForWALToBecomeAvailable/xlog.c.  A standby would give priority to
what is present in the local pg_wal or in the WAL archive before
switching to streaming.  If fetching a segment from the archive or the
local pg_wal fails, then a switch to streaming happens (of course if
primary_conninfo is defined).  There is nothing really linked to
replication slots in this case.
--
Michael