Re: [bug fix] PITR corrupts the database cluster

On Wed, Jul 24, 2013 at 10:57:14AM -0400, Tom Lane wrote:
> I wrote:
> > The only thing here that really bothers me is that a crash during DROP
> > DATABASE/TABLESPACE could leave us with a partially populated db/ts
> > that's still accessible through the system catalogs. ...
> > I guess one thing we could do is create a flag file, say
> > "dead.dont.use", in the database's default-tablespace directory, and
> > make new backends check for that before being willing to start up in
> > that database; then make sure that removal of that file is the last
> > step in DROP DATABASE.
>
> After a bit of experimentation, it seems there's a pre-existing way that
> we could do this: just remove PG_VERSION from the database's default
> directory as the first filesystem action in DROP DATABASE. If we
> crash before committing, subsequent attempts to connect to that database
> would fail like this:
>
> $ psql bogus
> psql: FATAL: "base/176774" is not a valid data directory
> DETAIL: File "base/176774/PG_VERSION" is missing.
>
> which is probably already good enough, though maybe we could add a HINT
> suggesting that the DB was incompletely dropped.
>
> To ensure this is replayed properly on slave servers, I'd be inclined to
> mechanize it by (1) changing remove_dbtablespaces to ensure that the
> DB's default tablespace is the first one dropped, and (2) incorporating
> remove-PG_VERSION-first into rmtree().

Where are we on this? Is there a TODO here?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +