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:23:12 |
Message-ID: | 3929.1532532192@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 10:37 AM, Andres Freund wrote:
>> What would we win here? Which scenario that's not contrived would be less bad due to the proposed change. This seems complexity for it's own sake.
> 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.
What's not contrived about it? Particularly the case of *only* deleting
pg_control and not any other critical file? I don't recall having heard
any such stories in the last twenty years.
Also, even if we added the complexity needed to write data into say
pg_control.bak, what then? You think that that would be any less
prone to indiscriminate rm'ing? Where and how would we document this,
and what's the odds that someone dumb enough to remove pg_control would
ever have read that part of the documentation?
I'm with Andres: this is a solution in search of a problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nico Williams | 2018-07-25 15:25:16 | Re: How can we submit code patches that implement our (pending) patents? |
Previous Message | Nico Williams | 2018-07-25 15:21:32 | Re: How can we submit code patches that implement our (pending) patents? |