Re: Missing pg_control crashes postmaster - Mailing list pgsql-hackers

From David Steele
Subject Re: Missing pg_control crashes postmaster
Date
Msg-id 25986d20-4a2b-f921-91ee-aa711aef19d6@pgmasters.net
Whole thread Raw
In response to Re: Missing pg_control crashes postmaster  (Andres Freund <andres@anarazel.de>)
Responses Re: Missing pg_control crashes postmaster  (Andres Freund <andres@anarazel.de>)
Re: Missing pg_control crashes postmaster  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 7/25/18 11:09 AM, Andres Freund wrote:
> On 2018-07-25 10:52:08 -0400, David Steele wrote:
> 
>> I favor the contrived scenario that helps preserve the current cluster
>> instead of a hypothetical newly init'd one.  I also don't think that users
>> deleting files out of a cluster is all that contrived.
> 
> But trying to limp on in that case, and that being helpful, is.

OK, I can't argue with that.  It would be wrong to continue operating 
without knowing what the damage is.

>> Adding O_CREATE to open() doesn't seem too complex to me.  I'm not really in
>> favor of the renaming idea, but I'm not against it either if it gets me a
>> copy of the pg_control file.
> 
> The problem is that that'll just hide the issue for a bit longer, while
> continuing (due to the O_CREAT we'll not PANIC anymore).  Which can lead
> to a lot of followup issues, like checkpoints removing old WAL that'd
> have been useful for data recovery.

So if a panic is the best thing to do, it might still be good to write 
out a copy of pg_control to another file and let the user know that it's 
there.  More information seems better than less to me.

Regards,
-- 
-David
david@pgmasters.net


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Early WIP/PoC for inlining CTEs
Next
From: Nico Williams
Date:
Subject: Re: How can we submit code patches that implement our (pending)patents?