| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Steele <david(at)pgmasters(dot)net> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Brian Faherty <anothergenericuser(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Missing pg_control crashes postmaster |
| Date: | 2018-07-25 15:33:14 |
| Message-ID: | 4170.1532532794@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Steele <david(at)pgmasters(dot)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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Steele | 2018-07-25 15:33:47 | Re: Missing pg_control crashes postmaster |
| Previous Message | Nico Williams | 2018-07-25 15:32:06 | Re: Early WIP/PoC for inlining CTEs |