Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 17 Oct 2023 08:38:40 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Steele <david@pgmasters.net>,
	Thomas Munro <thomas.munro@gmail.com>,
	Pg Hackers <pgsql-hackers@postgresql.org>,
	Stephen Frost <sfrost@snowman.net>
Subject: Re: The danger of deleting backup_label
Message-ID: <ZS3JgAA8c-zZvhGv@paquier.xyz>
References: <1330cb48-4e47-03ca-f2fb-b144b49514d8@pgmasters.net>
 <ZRY2vdlKJqhuZqGs@paquier.xyz>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="2R7igAGiwXkS6GXj"
Content-Disposition: inline
In-Reply-To: <CA+TgmoZ=HcNRv+wcPqMY+yYWE+VwOnPeq6tdHgRzire6NJg6vQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZS3JgAA8c-zZvhGv%40paquier.xyz>
Precedence: bulk


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

On Mon, Oct 16, 2023 at 12:25:59PM -0400, Robert Haas wrote:
> On Mon, Oct 16, 2023 at 11:45=E2=80=AFAM David Steele <david@pgmasters.ne=
t> wrote:
> > If you start from the last checkpoint (which is what will generally be
> > stored in pg_control) then the effect is pretty similar.
>=20
> If the backup didn't span a checkpoint, then restoring from the one in
> pg_control actually works fine. Not that I'm encouraging that. But if
> you replay WAL from the control file, you at least get the last
> checkpoint's worth of WAL; if you use pg_resetwal, you get nothing.

There's no guarantee that the backend didn't spawn an extra checkpoint
while a base backup was taken, either, because we don't fail hard at
the end of the BASE_BACKUP code paths if the redo LSN has been updated
since the beginning of a BASE_BACKUP.  So that's really *never* do it
except if you like silent corruptions.

> I don't really want to get hung up on this though. My main point here
> is that I have trouble believing that an error after you've already
> screwed up your backup helps much. I think what we need is to make it
> less likely that you will screw up your backup in the first place.

Yeah..  Now what's the best user experience?  Is it better for a base
backup to fail and have a user retry?  Or is it better to have the
backend-side backup logic do what we think is safer?  The former
(likely with a REDO check or similar), will likely never work on large
instances, while users will likely always find ways to screw up base
backups taken by latter methods.  A third approach is to put more
careful checks at restore time, and the latter helps a lot here.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmUtyYAACgkQnvQgOdby
QH0GLw/+Llgw1nSFDG/fPAe7imMVM4hK+NJfBMfTt+VKx+k5T0Z0ktJOyIHJuVPh
/cvvkN8CPSBfKRj3yN8OhwQXqrCp56rDWc+H8xzMAe2WmZsWblUmWJTILIlowJrw
hBZiOKwgwNsN6c88ZHkPG3zTRRbyem3syM2wwk7UBBPeoR961F9Zx2RmyuWfVLaU
eqNs3zFvs2PW8fm4BXQVSoMjGcD+PuI+ztCnEGYojyUym1K4xguq8xA06JcpVSbN
mFUqYQRBtNZyaXWk8JZ3NfvJwE7nw+/s90GzcYqA3E12QHiZnDr1jbhjVQBQyplJ
kseOGvVgxUI56yqsbuyobRv5U9TaGm1wAHeIiu/vzmO1KcfrP1qt7icAqF0BfIC+
VlMD1tiVIFH5MxbcwPcpymXOYZHoQ0kVO19+GfvVwp7l1v8wWOiw81ZiqjmO4vKh
RdLZn1Tf6Wr6yhcO8kEKY/uXsri9pyi8mp8eeebl6TKA/KUciTmZlzVhNBs9o9hk
lAgNaCddqEL0yD9I6PqVG7mB+FJ3p6UFFYJ3HLDN8DCwyfrv0KjLIOJxMH4uug8f
zH79XzkrHJg9zUyh2w/npWVCtWQJTDSmWqgCmFYh1vyBPy/3QLNdRxGY7IaNidt2
VP5jaJ2+EwTJ3PySZIfyQDnLM0FrC0Rl+ECZ1h3Dk5rRxrGp2uw=
=eBBG
-----END PGP SIGNATURE-----

--2R7igAGiwXkS6GXj--