Re: Missing pg_control crashes postmaster

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brian Faherty <anothergenericuser(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Missing pg_control crashes postmaster
Date: 2018-07-23 23:00:30
Message-ID: 6341.1532386830@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Brian Faherty <anothergenericuser(at)gmail(dot)com> writes:
> If a postmaster is running and the pg_control file is removed postgres
> will PANIC.

That's very intentional. Don't do it.

> There does not really seem to be a need for this behavior as all the
> information postgres needs is in memory at this point. I propose with
> a patch to just recreate pg_control on updates if it does not exist.

I would vote to reject any such patch; it's too likely to cause more
problems than it solves. Generally, if critical files like that one
have disappeared, trying to write new data isn't going to be enough
to fix it and could well result in more corruption.

As an example, imagine that you do "rm -rf $PGDATA; initdb" without
remembering to shut down the old postmaster first. Currently, the
old postmaster will panic/quit fairly promptly and no harm done.
The more aggressive it is at trying to "recover" from the situation,
the more likely it is to corrupt the new installation.

(Note that you would have to break a few other things in order to
make this particular scenario actually hazardous. My point is just
that there *are* reasons not to try to recover automatically.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-07-23 23:04:09 Re: "interesting" issue with restore from a pg_dump with a database-wide search_path
Previous Message Regina Obe 2018-07-23 22:56:30 RE: "interesting" issue with restore from a pg_dump with a database-wide search_path