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  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to