On Thu, Mar 10, 2022 at 7:22 PM Luca Ferrari <fluca1978@gmail.com> wrote:
>
> Hi all,
> a friend of mine has shown to me a "strange" configuration of its
> physical replication server (13): he has both primary_conninfo and
> primary_slot_name, with replication slots active when queried on the
> master. So far so good, but in the configuration he has also
> restore_command to restore archived WALs from a centralized location.
> Does this make sense?
> Because if the replica cannot connect to the master, it will not start
> at all (so I guess no restore_command will be executed). On the other
> hand if the replica can connect to the primary the WALs will be
> shipped by means of streaming.
> Am I missing something?
Yes, restore_command gets executed even in standby mode when
walreceiver is unable to receive wal from primary i.e. primary stopped
sending WAL, see some comments on it [1]. It looks like
restore_command in standby mode isn't mandatory, but is advisable I
guess. I hope that clarifies your question.
[1] WaitForWALToBecomeAvailable:
*
* If standby mode is turned off while reading WAL from stream, we move
* to XLOG_FROM_ARCHIVE and reset lastSourceFailed, to force fetching
* the files (which would be required at end of recovery, e.g., timeline
* history file) from archive or pg_wal. We don't need to kill WAL receiver
* here because it's already stopped when standby mode is turned off at
* the end of recovery.
*-------
*/
case XLOG_FROM_STREAM:
/*
* Failure while streaming. Most likely, we got here
* because streaming replication was terminated, or
* promotion was triggered. But we also get here if we
* find an invalid record in the WAL streamed from master,
* in which case something is seriously wrong. There's
* little chance that the problem will just go away, but
* PANIC is not good for availability either, especially
* in hot standby mode. So, we treat that the same as
* disconnection, and retry from archive/pg_wal again. The
* WAL in the archive should be identical to what was
* streamed, so it's unlikely that it helps, but one can
* hope...
*/
Regards,
Bharath Rupireddy.
