Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 5 Feb 2026 09:40:58 +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: <aYPnGiQQAcDiUNrB@paquier.xyz>
References: <CAMm1aWZ9Tv=Wrx52_2Ppw+6ULf_twRZuQm=ZWLA_a-kXWykHkQ@mail.gmail.com>
 <aUIoTCHzW8sdDpe_@paquier.xyz>
 <CAMm1aWb47v9Bx40P1_6YpRxxKi9XSwjAV_bLbFxx66Rg8o3+=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="OhPlcQwJAAszvatW"
Content-Disposition: inline
In-Reply-To: <CAMm1aWb47v9Bx40P1_6YpRxxKi9XSwjAV_bLbFxx66Rg8o3+=g@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aYPnGiQQAcDiUNrB%40paquier.xyz>
Precedence: bulk


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

On Mon, Dec 29, 2025 at 08:39:08PM +0530, Nitin Jadhav wrote:
> Apologies for the delay.
> At a high level, the recovery startup cases we want to test fall into
> two main buckets:
> (1) with a backup_label file and (2) without a backup_label file.

For clarity's sake, we are talking about lowering this one in
xlogrecovery.c, which relates to the code path where these is no
backup_label file:
ereport(PANIC,
        errmsg("could not locate a valid checkpoint record at %X/%08X",
               LSN_FORMAT_ARGS(CheckPointLoc)));

> From these two situations, we can cover the following scenarios:
> 1) Primary crash recovery without a backup_label =E2=80=93 Delete the WAL
> segment containing the checkpoint record and try starting the server.

Yeah, let's add a test for that.  It would be enough to remove the
segment that includes the checkpoint record.  There should be no need
to be fancy with injection points like the other test case from
15f68cebdcec.

> 2) Primary crash recovery with a backup_label =E2=80=93 Take a base backup
> (which creates the backup_label), remove the checkpoint WAL segment,
> and start the server with that backup directory.

Okay.  I don't mind something here, for the two FATAL cases in the
code path where the backup_label exists:
- REDO record missing with checkpoint record found.  This is similar
to 15f68cebdcec.
- Checkpoint record missing.
Both should be cross-checked with the FATAL errors generated in the
server logs.

> 3) Standby crash recovery =E2=80=93 Stop the standby, delete the checkpoi=
nt
> WAL segment, and start it again to see how standby recovery behaves.

In this case, we need to have a restore_command set anyway, no,
meaning that we should never fail?  I don't recall that we have a test
for that, currently, where we could look at the server logs to check
that a segment has been retrieved because the segment that includes
the checkpoint record is missing..

> 4) PITR / archive=E2=80=91recovery =E2=80=93 Remove the checkpoint WAL se=
gment and
> start the server with a valid restore_command so it enters archive
> recovery.

Same as 3) to me, standby mode cannot be activated without a
restore_command and the recovery GUC checks are done in accordance to
the signal files before we attempt to read the initial checkpoint
record.

> Tests (2) and (4) are fairly similar, so we can merge them if they
> turn out to be redundant.
> These are the scenarios I have in mind so far. Please let me know if
> you think anything else should be added.

For the sake of the change from the PANIC to FATAL mentioned at the
top of this message, (1) would be enough.

The two cases of (2) I'm mentioning would be nice bonuses.  I would
recommend to double-check first if we trigger these errors in some
tests of the existing tests, actually, perhaps we don't need to add
anything except a check in some node's logs for the error string
patterns wanted.
--
Michael

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

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

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmmD5xoACgkQnvQgOdby
QH1CsQ//QqmCBfaHFNQWsQZyxmLuOnzU9k1CEDgsrcckKqfyOEeOZljA6fBve4fj
vRLdpj0MChS1T3/Mslgxw5MrINFEt9Ma2kRJM7TzCjBwo+Rd9brGTYiRUGJfud3I
01Sz8+quvZwY2V2i1xtdVP1/IBeT4k/MF2IXQTSbYBkNjmSRW4j8e7mGvLVKrkjO
SevuvhXn5hyYHggS3LjU11Wp9miItZMqmIYiSGxQCKNLgY81ovUcF+NjNmlneobR
/TJZEEm3143Un8WqJi21TTB4NQ+nvze4iWFp3EJ0U9lZd8bELRXeKo94adRbrC+/
R7MiBsOveUuAA0ZtRBdq4z8yS/Bld+MOLIWAPvw9OCon7w5lSyvVM/Q1gfA5ZHfb
nax6KZ+NAbKoiDLPd0YWRgV4jWXSTHg2kzvG8K3JjYq7cMzBetZ43M0tvlBaAnFI
B6IPXII/z3ORDCFOwWAFpnitiRosi0pL2VMVJnSss+IxIa+2MVcIR6Anp9zt5vKk
I3mI++CeMb/n7BsV018bCGAMKUztSF8wwnaXLeiC6AFbACY5mE44l53FRNk476mD
DXS/T0kRs23vHGAhPBYfb7XfhbE8d976q4IOQzyYvQYgr6abgP3//26yXF/+aedx
EqF31FSwzLbG++jDlPqC4yh6hGa06T/2FGjVkLKXFr/fOpxghjo=
=w4RO
-----END PGP SIGNATURE-----

--OhPlcQwJAAszvatW--