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().
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
