public inbox for [email protected]
help / color / mirror / Atom feedAmbiguity in restore_command for recovery.conf
2+ messages / 2 participants
[nested] [flat]
* Ambiguity in restore_command for recovery.conf
@ 2018-09-18 16:10 PG Doc comments form <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: PG Doc comments form @ 2018-09-18 16:10 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
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.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Ambiguity in restore_command for recovery.conf
@ 2018-09-19 02:42 Michael Paquier <[email protected]>
parent: PG Doc comments form <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Michael Paquier @ 2018-09-19 02:42 UTC (permalink / raw)
To: [email protected]; [email protected]
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
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2018-09-19 02:42 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-09-18 16:10 Ambiguity in restore_command for recovery.conf PG Doc comments form <[email protected]>
2018-09-19 02:42 ` Michael Paquier <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox