Re: Fix crash during recovery when redo segment is missing

From: Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Fix crash during recovery when redo segment is missing
Date: 2025-12-09 04:00:41
Message-ID: CAMm1aWadkN6NFGerHJSm78GPXM5=RcBfBfYkoXyFhAATQLOxGg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Using PANIC is an inherited historical artifact that has been
> introduced around 4d14fe0048cf with the introduction of WAL. There
> was nothing like archiving or even base backup back then. Switching
> the existing surrounding one to also use a FATAL is something that
> seems worth considering to me for the checkpoint record, at least
> based on the pattern that there could be a driver error even if there
> is no backup_label file (aka for example the case of FS-levelsnapshots
> with one partition used for the data folder, no?).

Thanks for explaining the historical context. I agree that switching
the existing PANIC to FATAL for the checkpoint record case makes
sense. I will include this change in the next patch if there are no
objections from others.

> This offers bonus points in the shape of more tests like the one you
> have sent upthread. It's not something that I would backpatch as it
> is a behavior change, but I'm open to seeing that as an improvement in
> usability for future releases: PANIC is for cases that should never
> happen for internal states, due to an internal logic error, or an OS
> going crazy. Here we have a should-no-happen case triggered by a
> user, and a FATAL still provides the same information about what's
> wrong. Let's make such changes separate patches, of course, depending
> on what we find on the way.

Thanks for the suggestion. I will keep that in mind and look to add
more such tests in future.

Best Regards,
Nitin Jadhav
Azure Database for PostgreSQL
Microsoft

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-12-09 04:12:34 Re: pgsql: Add pg_atomic_unlocked_write_u64
Previous Message Sami Imseih 2025-12-09 03:57:15 Re: [Proposal] Adding callback support for custom statistics kinds