Re: Missing pg_control crashes postmaster

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

In response to

Browse pgsql-hackers by date

  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?