MIME-Version: 1.0
References: 
 <CAMm1aWZ9Tv=Wrx52_2Ppw+6ULf_twRZuQm=ZWLA_a-kXWykHkQ@mail.gmail.com>
 <aUIoTCHzW8sdDpe_@paquier.xyz>
 <CAMm1aWb47v9Bx40P1_6YpRxxKi9XSwjAV_bLbFxx66Rg8o3+=g@mail.gmail.com>
 <aYPnGiQQAcDiUNrB@paquier.xyz>
 <CAMm1aWZQfMm1Wn=cMorqNsqdySERZCgV2JL87jVy4yCmLY8xvg@mail.gmail.com>
 <aZaO8pPLlYmcNaB2@paquier.xyz>
 <CAMm1aWZbQ-Acp_xAxC7mX9uZZMH8+NpfepY9w=AOxbBVT9E=uA@mail.gmail.com>
 <aa-W7D-1ONpwIxwO@paquier.xyz>
In-Reply-To: <aa-W7D-1ONpwIxwO@paquier.xyz>
From: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
Date: Fri, 20 Mar 2026 19:56:46 +0530
Message-ID: 
 <CAMm1aWZOrSePJHns2LHdvHbTj1y-40Jgg4um2AwhQGDGotPiyQ@mail.gmail.com>
Subject: 
 =?UTF-8?Q?Re=3A_Change_checkpoint=E2=80=91record=E2=80=91missing_PANIC_to_FA?=
	=?UTF-8?Q?TAL?=
To: Michael Paquier <michael@paquier.xyz>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAMm1aWZOrSePJHns2LHdvHbTj1y-40Jgg4um2AwhQGDGotPiyQ%40mail.gmail.com>
Precedence: bulk

> There could be one possibility for 0001 to be unstable, actually.  One
> could imagine that by getting the segment from a live server things
> could fail: if the run is very slow then we may finish with an
> incorrect record.  It would be possibe to use pg_controldata once the
> server has been shut down, but we should be on the same segment anyway
> because nothing happens on the server, so I have let the test are you
> have suggested, and applied this one.  You have missed an update in
> meson.build, and I am not sure that there was a need for renaming 050,
> either.

Good catch=E2=80=94thanks. This does seem like it could apply to the earlie=
r
redo=E2=80=91record=E2=80=91missing case as well. That said, since there=E2=
=80=99s no activity
on the server during the test, it should be safe as you mentioned. My
apologies for missing the meson.build update again=E2=80=94thanks for takin=
g
care of it. On the renaming, I was aiming to separate things into four
tests to make the differences explicit, but I=E2=80=99m happy to stick with
two test files.

> These two are very close to the existing tests that we have on HEAD
> now, could it be better to group them together instead?  Particularly,
> 054 reuses the injection point trick in what is clearly a copy-paste
> taken from 050.  Avoiding this duplication may be nice.

That's a good point. I agree these new cases are very close to what we
already have on HEAD. I can rework this to avoid duplication by
grouping them with the existing tests.

Best Regards,
Nitin Jadhav
Azure Database for PostgreSQL
Microsoft

On Tue, Mar 10, 2026 at 9:28=E2=80=AFAM Michael Paquier <michael@paquier.xy=
z> wrote:
>
> On Fri, Mar 06, 2026 at 11:02:41AM +0530, Nitin Jadhav wrote:
> > Patch 0001 adjusts the error severity during crash recovery when the
> > checkpoint record referenced by pg_control cannot be located and no
> > backup_label file is present. The error is lowered from PANIC to
> > FATAL. This patch also adds a new TAP test that verifies startup fails
> > with a clear FATAL error. The test is straightforward: it removes the
> > WAL segment containing the checkpoint record and confirms that the
> > server reports the expected error.
>
> There could be one possibility for 0001 to be unstable, actually.  One
> could imagine that by getting the segment from a live server things
> could fail: if the run is very slow then we may finish with an
> incorrect record.  It would be possibe to use pg_controldata once the
> server has been shut down, but we should be on the same segment anyway
> because nothing happens on the server, so I have let the test are you
> have suggested, and applied this one.  You have missed an update in
> meson.build, and I am not sure that there was a need for renaming 050,
> either.
>
> > Missing checkpoint WAL segment referenced by backup_label:
> > This test uses an online backup to create a backup_label file,
> > extracts the checkpoint record information from it, removes the
> > corresponding WAL segment, and verifies that the server reports the
> > expected error.
> >
> > Missing redo WAL segment referenced by the checkpoint:
> > In this test, redo and checkpoint records are forced into different
> > WAL segments using injection points. A cold backup is then taken, with
> > an explicit backup_label created in the restored cluster. The WAL
> > segment containing the redo record is removed, and startup is expected
> > to fail with the appropriate error message.
>
> These two are very close to the existing tests that we have on HEAD
> now, could it be better to group them together instead?  Particularly,
> 054 reuses the injection point trick in what is clearly a copy-paste
> taken from 050.  Avoiding this duplication may be nice.
> --
> Michael