Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 17 Dec 2025 12:49:32 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Change =?utf-8?B?Y2hlY2twb2ludOKAkXJl?=
 =?utf-8?Q?cord=E2=80=91missing?= PANIC to FATAL
Message-ID: <aUIoTCHzW8sdDpe_@paquier.xyz>
References: 
 <CAMm1aWZ9Tv=Wrx52_2Ppw+6ULf_twRZuQm=ZWLA_a-kXWykHkQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="SYzmm/7UfUdQUk/S"
Content-Disposition: inline
In-Reply-To: 
 <CAMm1aWZ9Tv=Wrx52_2Ppw+6ULf_twRZuQm=ZWLA_a-kXWykHkQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aUIoTCHzW8sdDpe_%40paquier.xyz>
Precedence: bulk


--SYzmm/7UfUdQUk/S
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 16, 2025 at 04:25:37PM +0530, Nitin Jadhav wrote:
> it seems reasonable to align the checkpoint=E2=80=91record=E2=80=91missin=
g case as well.
> The existing PANIC dates back to an era before online backups and archive
> recovery existed, when external manipulation of WAL was not expected and
> such conditions were treated as internal faults. With all such features, =
it
> is much more realistic for WAL segments to go missing due to operational
> issues, and such cases are often recoverable. So switching this to FATAL
> appears appropriate.
>=20
> Please share your thoughts.

FWIW, I think that we should lift the PANIC pattern in this case, at
least to be able to provide more tests around the manipulation of WAL
segments when triggering recovery, with or without a backup_label as
much as with or without a recovery/standby.signal defined in the tree.=20
The PANIC pattern to blow up the backend when missing a checkpoint
record at the beginning of recovery is a historical artifact of
4d14fe0048cf.  The backend has evolved a lot since, particularly with
WAL archives that came much later than that.  Lowering that to a FATAL
does not imply a loss of information, just the lack of a backtrace
that can be triggered depending on how one has set of a cluster to
start (say a recovery.signal was forgotten and pg_wal/ has no
contents, etc.).  And IMO I doubt that a trace is really useful anyway
in this specific code path.

I'd love to hear the opinion of others on the matter, so if anybody
has comments, feel free.

I'd be curious to look at the amount of tests related to recovery
startup you have in mind anyway, Nitin.
--
Michael

--SYzmm/7UfUdQUk/S
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmlCKEwACgkQnvQgOdby
QH1BgRAAmTuC8K5dkWGooNbujwBkCs0zbHqT9VMSLDba0GsTYwuRq71L3tlKJikD
6enqBsEldWAl68m2UGLM9NT7E9+qRb/frhLQU4M/0iAd0q4Q+xOHluXVe+bk9Ayv
2jv9xKE+2NShTvcAWz+q1Rf9/ENSX4f2vtUGiswjaaufp9fWQNIA/QzJNGdPhWAc
py3UaLD1Mg3VOUad8gd+Ks2qIfMO9M1HkhdDfYECQLy39DcJOxVnYrF9tzsbuPlM
2HlG5SBItLNYi4Lh9wnglQTK6u2wumFUFRqdcE6vRXnqsvdiv94qgozAICYlCAfz
i0yjoL01H1vDEAZ3aSN/Q+cGfuZD8cQMw8C1PH7rc5MPTuyVTY2AF+4B3ZWmmOGZ
TrUrMP5w2cK+oK14QrOsxvsw1SD37zf5xxbeOP/4SzBcDKhKPeHGqD56b11Qykcs
u+1rEQVSFAyuFBR6AsrmrBESgVm/0Llor14ap37G1ArdWkXdSlB/tATzskMw7Yd+
zBuwFgdHbSoHVEayz6yKacPW7ERDPtV81G1dWF3pBrb+HujbQNT5lazLQkDcyN7e
ETGUyGkboo0vu+rNNL5LJNVZK9rMk78kaPFR2eFGjecGqcwToYg/ZUFZUWvX6xWM
G/SeDaNphxz4fPicAwAtAE4jJpQsM7CyhhbiV1b9YGdsbzkLMTs=
=pP/G
-----END PGP SIGNATURE-----

--SYzmm/7UfUdQUk/S--