On 7/25/18 11:33 AM, Tom Lane wrote:
David Steele <da...@pgmasters.net> writes:
On 7/25/18 11:09 AM, Andres Freund wrote:
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.
I'm still dubious that this is fixing any real-world problem that is
more pressing than the problems it would create. If you're asked to
resuscitate a dead cluster, do you trust pg_control.bak if you find
it? Maybe it's horribly out of date (consider likelihood that someone
removed pg_control more than once, having got away with that the first
time). If there's both that and pg_control, which do you trust?
It would need to be a manual operation. I don't think automating it
would be a good idea for the reasons that Andres has enumerated.
Perhaps making pg_resetwal a bit smarter in these scenarios would be the
way to go. It's already the tool of last resort so this kind of
manipulation might be a better fit there.
Regards,
--
-David
da...@pgmasters.net