Horton

Re: Fix crash during recovery when redo segment is missing

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2025-12-16T07:46:56Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add TAP test to check recovery when redo LSN is missing

  2. Fail recovery when missing redo checkpoint record without backup_label

On Tue, Dec 16, 2025 at 12:40:25PM +0530, Nitin Jadhav wrote:
> I was planning to start a separate thread for this point, but since it
> was a small change I had included it here earlier. I understand the
> considerations involved even for these minor adjustments. I will start
> a separate thread for this.

An argument that would sound in favor of a switch from PANIC to FATAL
is the testing side: if one removes the segment where the checkpoint
record resides, we crash.  Of course, one should not do that, but I
have been wondering for years if it would not be a good thing idea to
lift that a bit and expand the in-core tests and how we expect the
startup process to deal with things.  One of my line of thoughts is
that the PANIC behavior is inherited from a time where we did not have
online backups and archive recovery, where such manipulations have
never been possible to start with because WAL segments had a full life
only linked to the backend in pg_wal.  Perhaps others don't agree with
that, that's fine.

It would be easy enough to expand the test added by 15f68cebdcec to
check the no-checkpoint case, of course.  I just did that this morning
while quickly testing various recovery patterns, which was easier than
rewriting a new script for the job.  :)
--
Michael