Date: Wed, 19 Sep 2018 11:42:50 +0900
From: Michael Paquier <michael@paquier.xyz>
To: cjames@emolecules.com, pgsql-docs@lists.postgresql.org
Subject: Re: Ambiguity in restore_command for recovery.conf
Message-ID: <20180919024250.GE1650@paquier.xyz>
References: <153728701749.28483.6427522510493541629@wrigleys.postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="NQTVMVnDVuULnIzU"
Content-Disposition: inline
In-Reply-To: <153728701749.28483.6427522510493541629@wrigleys.postgresql.org>
Precedence: bulk


--NQTVMVnDVuULnIzU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--NQTVMVnDVuULnIzU
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAluht6oACgkQnvQgOdby
QH3I/Q//fjMcudB2E8CqJSULTyc7Co2CzzliikCOVcWIYw7rOazYw254e8LN+913
OSWIZc5CNH0Ob455d3RybyUABaPXYJi7E9ZxN0rM4jFFrj7SPjSqmir+9v2VnOKd
D3w5VjwLhAlxeTeKACzZMdOAaKYmIUQor9C4LVxYmjuMY9TnpJikur/1nKrm5+R+
XYDWN9pNxC75oj+6C4YGfyx+6vl5GhinSVGcnGuST6c4YqYGGOotdiIGua4EnrX/
Hx5+8BI6BA61vMkVwlqhOsBv0aSzTkt7Vlo838gGCuHNVVG7jv8Owhkd4p8oR95R
uZ/vvZx0bDhZl1W9Sl/XH1pNEbAxu9+Ss5fy/gMU6IDtfyA3W3IbVdYU8lL4p3/t
04Idd4PMxDqD7i7GLTs+UZYXemxgF403vG7PVeT7n6S5CB2DjazmLuG//GwkF5Ba
1vBzBsde1lpiNBk5epquVOtsb04WQB7NlCYp8HbDT13Kz2O7vgqd2yD37CTGLb1l
ti06w5/nQDBhwwUPILgXO4ZJAw43Gr0h7w1X1hVhsfv5CeY1EoLAEIbL8DBtwcwf
rZ+sCkhpas0nlYfnECeXS5M1M8Jn/7cEiq9BWP9crMUNJ4w/D4dD3WF5BJ4ClJXz
/du2wkohyGe8dXs/kKTvhzEoZDMzu18KpOKK4ALUgwzg01kT9iQ=
=KnqJ
-----END PGP SIGNATURE-----

--NQTVMVnDVuULnIzU--