| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
| 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-16 07:46:56 |
| Message-ID: | aUEOcOK9G9Ri3TnE@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-12-16 07:55:28 | Re: [PATCH]Remove the redundant assignment |
| Previous Message | Michael Paquier | 2025-12-16 07:39:05 | Re: Change the signature of pgstat_report_vacuum() so that it's passed a Relation |