Date: Tue, 17 Oct 2023 15:17:47 -0400
From: Stephen Frost <sfrost@snowman.net>
To: David Steele <david@pgmasters.net>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Thomas Munro <thomas.munro@gmail.com>,
	Michael Paquier <michael@paquier.xyz>,
	Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: The danger of deleting backup_label
Message-ID: <ZS7d24o3p87PaVHt@tamriel.snowman.net>
References: <0e088834-aa39-ed09-3ec7-31c13c629a20@pgmasters.net>
 <CA+hUKGLok_wrosp8Q6DA+mkhtWyQSEwPSKP=2p5bnLZC=FGpaQ@mail.gmail.com>
 <65825be1-e79a-46f4-9d9f-4ff95a10e378@pgmasters.net>
 <e05f20f9-6f91-9a70-efab-9a2ae472e65d@pgmasters.net>
 <CA+TgmoZkdrWyd7KiPFHaJBg+tjM3UFrqOBK1EtG3NtVs97-7Xw@mail.gmail.com>
 <9dc67363-5200-7395-3ddb-b50171800bc6@pgmasters.net>
 <CA+TgmoZ=HcNRv+wcPqMY+yYWE+VwOnPeq6tdHgRzire6NJg6vQ@mail.gmail.com>
 <12bf9438-f229-5048-dd91-440f3b1880e9@pgmasters.net>
 <CA+TgmoYYcGC-aErHmYyqggST4Q5SKqeZDxikgg_BTi=3tZGJQw@mail.gmail.com>
 <aa892ab1-48f7-78a2-44b8-76b4495b77d2@pgmasters.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="P0FuMMRRmW3G7dTQ"
Content-Disposition: inline
In-Reply-To: <aa892ab1-48f7-78a2-44b8-76b4495b77d2@pgmasters.net>
User-Agent: Mutt/2.1.4 (2021-12-11)
Archived-At: <https://www.postgresql.org/message-id/ZS7d24o3p87PaVHt%40tamriel.snowman.net>
Precedence: bulk


--P0FuMMRRmW3G7dTQ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* David Steele (david@pgmasters.net) wrote:
> On 10/16/23 15:06, Robert Haas wrote:
> > On Mon, Oct 16, 2023 at 1:00=E2=80=AFPM David Steele <david@pgmasters.n=
et> wrote:
> > > After some agonizing (we hope) they decide to delete backup_label and,
> > > wow, it just works! So now they merrily go on their way with a corrup=
ted
> > > cluster. They also remember for the next time that deleting backup_la=
bel
> > > is definitely a good procedure.
> > >=20
> > > The idea behind this patch is that deleting backup_label would produc=
e a
> > > hard error because pg_control would be missing as well (if the backup
> > > software did its job). If both pg_control and backup_label are present
> > > (but pg_control has not been loaded with the contents of backup_label,
> > > i.e. it is the running copy from the backup cluster) we can also erro=
r.
> >=20
> > I mean, I think we're just going in circles, here. I did and do
> > understand, but I didn't and don't agree. You're hypothesizing a user
> > who is willing to do ONE thing that they shouldn't do during backup
> > restoration (namely, remove backup_label) but who won't be willing to
> > do a SECOND thing that they shouldn't do during backup restoration
> > (namely, run pg_resetwal).
>=20
> In my experience the first case is much more likely than the second. Your
> experience may vary.

My experience (though perhaps not a surprise) mirrors David's.

> Anyway, I think they are pretty different. Deleting backup label appears =
to
> give a perfectly valid restore. Running pg_resetwal is more clearly (I
> think) the nuclear solution.

Right, and a delete of backup_label is just an 'rm' that folks may think
"oh, this is just some leftover thing that isn't actually needed".

OTOH, pg_resetwal has an online documentation page and a man page that's
very clear that it's only to be used as a last resort (perhaps we should
pull that into the --help output too..?).  It's also pretty clear that
pg_resetwal is actually changing things about the cluster while nuking
backup_label doesn't *seem* to be in that same category, even though we
all know it is because it's needed once recovery begins.

I'd also put out there that while people don't do restore testing
nearly as much as they should, they tend to at _least_ try to do it once
after taking their first backup and if that fails then they try to figure
out why and what they're not doing right.

Thanks,

Stephen

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

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

iQIzBAABCgAdFiEEwf6gbxKhD863zrx/7WyKOINHZFUFAmUu3dkACgkQ7WyKOINH
ZFWzThAAln+GWy6VP0VCcpooAAu+2TF611+ICmrcfK1Q5u98WJSsmA8sigSY1d8Z
ZBkDlY7BokTURrs2KGrLkQ+rXk+f3q4iGd7oI8X59gfiAtwI0p9q71kqzQ5f59GY
jJo1+0rdD8i7wD+rfs6V5IeVeRqcs1cxq8NBOrZxwN0Ii3Vl2sRhU1ocCkh5RTHf
/7Yi56TLQuZgFhd+CcXSUt+QYlVZRS9BMZRwdj/bI1vPyrXhbwQYzw22rSHUxTGr
GRbRFfV8Ld+iuNpoeiPkNtWNXws1G6Q9l8ziRM9m4EOrqUvo+h84oTVi1aXImJ+d
CPxWHSkgGP1UcqeUq8Bu4IdYDLMeHu5U48b0gc3ZDwk5htCawDcPgpSrgHWYh3Rt
QaJLOXfYsDB5jkt02zmKSUfClkx8iKQmn8F/QjToGWa7ektVRCymX+xE/qFcHaFM
KbDGj4awGum3pQLWVJTYDjQW6ubaZP6WqlBI2L5Ef00i0KDvogJQvDsTI60JOEkb
Zr6E7M5+yxprlHd2ZovCGerOJVANpJYJ31knv4EDUTSiUioeOQl0EEtevaOAap2V
OyXCbZBp255BSrX3z8cpNxBiGrUzCz42dOlIqFrXpJD0jbKtDqfChoAs33dj1ZJ6
wEwdUndz5ohZLQCg5kS/lneAKP7vBrwhzrS74wy0OJEcL7HoAms=
=Su4J
-----END PGP SIGNATURE-----

--P0FuMMRRmW3G7dTQ--