MIME-Version: 1.0
From: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
Date: Tue, 16 Dec 2025 16:25:37 +0530
Message-ID: 
 <CAMm1aWZ9Tv=Wrx52_2Ppw+6ULf_twRZuQm=ZWLA_a-kXWykHkQ@mail.gmail.com>
Subject: 
 =?UTF-8?Q?Change_checkpoint=E2=80=91record=E2=80=91missing_PANIC_to_FATAL?=
To: Pg Hackers <pgsql-hackers@postgresql.org>
Cc: Michael Paquier <michael@paquier.xyz>
Content-Type: multipart/alternative; boundary="000000000000876bad06460f93c9"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMm1aWZ9Tv%3DWrx52_2Ppw%2B6ULf_twRZuQm%3DZWLA_a-kXWykHkQ%40mail.gmail.com>
Precedence: bulk

--000000000000876bad06460f93c9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

While working on [1], we discussed whether the redo-record-missing error
should be a PANIC or a FATAL. We concluded that FATAL is more appropriate,
as it is more appropriate for the current situation and achieves the
intended behavior and also it is consistent with the backup_label path,
which already reports FATAL in the same scenario.

However, when the checkpoint record is missing, the behavior remains
inconsistent: Without a backup_label, we currently raise a PANIC. With a
backup_label, the same code path reports a FATAL.Since we have already made
the redo=E2=80=91record=E2=80=91missing case to FATAL in 15f68ce
<https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommit;h=3D15f68=
cebdcec>,
it seems reasonable to align the checkpoint=E2=80=91record=E2=80=91missing =
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.

Please share your thoughts.

I am happy to share a patch including a TAP test to cover this behavior
once we agree to proceed.

[1]:
https://www.postgresql.org/message-id/flat/CAMm1aWaaJi2w49c0RiaDBfhdCL6ztbr=
9m%3DdaGqiOuVdizYWYaA%40mail.gmail.com

Best Regards,
Nitin Jadhav
Azure Database for PostgreSQL
Microsoft

--000000000000876bad06460f93c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div>While working on [1], we disc=
ussed whether the redo-record-missing error should be a PANIC or a FATAL. W=
e concluded that FATAL is more appropriate, as it is more appropriate for t=
he current situation and achieves the intended behavior and also it is cons=
istent with the backup_label path, which already reports FATAL in the same =
scenario.<br><br>However, when the checkpoint record is missing, the behavi=
or remains inconsistent: Without a backup_label, we currently raise a PANIC=
. With a backup_label, the same code path reports a FATAL.Since we have alr=
eady made the redo=E2=80=91record=E2=80=91missing case to FATAL in <a href=
=3D"https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommit;h=3D15=
f68cebdcec">15f68ce</a>, it seems reasonable to align the checkpoint=E2=80=
=91record=E2=80=91missing case as well. The existing PANIC dates back to an=
 era before online backups and archive recovery existed, when external mani=
pulation of WAL was not expected and such conditions were treated as intern=
al faults. With all such features, it is much more realistic for WAL segmen=
ts to go missing due to operational issues, and such cases are often recove=
rable. So switching this to FATAL appears appropriate.<br><br>Please share =
your thoughts.<br><br>I am happy to share a patch including a TAP test to c=
over this behavior once we agree to proceed.<br><br>[1]: <a href=3D"https:/=
/www.postgresql.org/message-id/flat/CAMm1aWaaJi2w49c0RiaDBfhdCL6ztbr9m%3Dda=
GqiOuVdizYWYaA%40mail.gmail.com">https://www.postgresql.org/message-id/flat=
/CAMm1aWaaJi2w49c0RiaDBfhdCL6ztbr9m%3DdaGqiOuVdizYWYaA%40mail.gmail.com</a>=
<br><br>Best Regards,<br>Nitin Jadhav<br>Azure Database for PostgreSQL<br>M=
icrosoft</div>

--000000000000876bad06460f93c9--