Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 29 Sep 2023 08:59:39 +0900
From: Michael Paquier <michael@paquier.xyz>
To: David Steele <david@pgmasters.net>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-hackers@lists.postgresql.org, zxwsbg12138@gmail.com,
	david.zhang@highgo.ca
Subject: Re: Requiring recovery.signal or standby.signal when recovering with
 a backup_label
Message-ID: <ZRYTa6Qs9Ecseux1@paquier.xyz>
References: <ZArVOMifjzE7f8W7@paquier.xyz>
 <20230928.125851.2051261991058034791.horikyota.ntt@gmail.com>
 <4f94351c-24e2-cf32-82d3-1e1bf89a0f5e@pgmasters.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="EoSerEH9n2n70nEw"
Content-Disposition: inline
In-Reply-To: <4f94351c-24e2-cf32-82d3-1e1bf89a0f5e@pgmasters.net>
Archived-At: <https://www.postgresql.org/message-id/ZRYTa6Qs9Ecseux1%40paquier.xyz>
Precedence: bulk


--EoSerEH9n2n70nEw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 28, 2023 at 04:23:42PM -0400, David Steele wrote:
> After some playing around, I find I agree with Michael on this, i.e. requ=
ire
> at least standby.signal when a backup_label is present.
>=20
> According to my testing, you can preserve the "independent server"
> functionality by setting archive_command =3D /bin/false. In this case the
> timeline is not advanced and recovery proceeds from whatever is available=
 in
> pg_wal.

I've seen folks depend on such setups in the past, actually, letting a
process outside Postgres just "push" WAL segments to pg_wal instead of
Postgres pulling it with a restore_command or a primary_conninfo for a
standby.

> I think this type of recovery from a backup label without a timeline chan=
ge
> should absolutely be the exception, not the default as it seems to be now.

This can mess up archives pretty easily, additionally, so it's not
something to encourage..

> If the server is truly independent, then the timeline change is not
> important. If the server is not independent, then the timeline change is
> critical.
>=20
> So overall, +1 for Michael's patch, though I have only read through it and
> not tested it yet.

Reviews, thoughts and opinions are welcome.

> One comment, though, if we are going to require recovery.signal when
> backup_label is present, should it just be implied? Why error and force t=
he
> user to create it?

That's one thing I was considering, but I also cannot convince myself
that this is the best option because the presence of recovery.signal
or standby.standby (if both, standby.signal takes priority) makes it
clear what type of recovery is wanted at disk level.  I'd be OK if
folks think that this is a sensible consensus, as well, even if I
don't really agree with it.

Another idea I had was to force the creation of recovery.signal by
pg_basebackup even if -R is not used.  All the reports we've seen with
people getting confused came from pg_basebackup that enforces no
configuration.

A last thing, that had better be covered in a separate thread and
patch, is about validateRecoveryParameters().  These days, I'd like to
think that it may be OK to lift at least the restriction on
restore_command being required if we are doing recovery to ease the
case of self-contained backups (aka the case where all the WAL needed
to reach a consistent point is in pg_wal/ or its tarball)
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmUWE2sACgkQnvQgOdby
QH2bGxAAhtuJzpS0aw36nJarzT0RHAOs/HhmnpNvun0ws10gSUyyRHlL+OyGwCzH
C0bQiLE0qZTf1AmLmW8rpt07g2HmrxvFQBdfm66i29XXlOnAIukfhhOS3/noTfsq
VVIFtWvArRrdRwENa/Flb2xJBO/zPzwOa7wyCvbxe9HnffCi5ULEIQ8Z63QCmg4g
5s7DGu/JdVMJkClNjCAJFIB2YJgz/b0aznZXKcExCOpHUzXY/umegPVAIU6jkfhw
JSXPwGWQ//Sv+valsuC7d5qF5v+drnrOo/67qCnxsfSi2TtHjedkpz9DRY3ivO1U
G1a9BxHr0nljqej4zWXJh+uLO56IceBd124itaT4vF7jTtggYT6TMn28A5KlAa9q
HoMzorVz/GPzxUKWySawzIclX+vAd1QxTRV0rXBeO3l3cpbNAtXBLb4sMKGgtHk2
rI765w2MjE8Uf+Y/hdg2GUKF4eFaYF4RQscAMNxYeI1PsPr9t1CCYixTvv5M/QpA
qocgmhgZr4WSUOmUMZeRG/PdrleUHU5W0hm9WOASys+U+cYuwawhgclPPzHrIyLx
wl+hZtbJEodKLgxEUzZX0wm8tb6UIyN5VSj8Y5bLE6LVmOlcArK3RsMqjt2guecd
TrzklYCuW/qESpIiDW/gHe+NWdHjy9rWp1BWWd0ltcXH49I1XkA=
=zXOt
-----END PGP SIGNATURE-----

--EoSerEH9n2n70nEw--