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: http://www.postgresql.org/mailpref/pgsql-hackers
