On 25.11.2014 18:11, Heikki Linnakangas wrote: > On 11/25/2014 06:06 PM, Christoph Berg wrote: > >> db1 is registered in pg_database, but the directory is missing on >> disk. > > Yeah, DROP DATABASE cheats. It deletes all the files first, and commits > the transaction only after that. There's this comment at the end of > dropdb() function: > >> /* >> * Force synchronous commit, thus minimizing the window between >> removal of >> * the database files and commital of the transaction. If we crash >> before >> * committing, we'll have a DB that's gone on disk but still there >> * according to pg_database, which is not good. >> */ > > So you could see the same after crash recovery, but it's a lot easier to > reproduce with PITR.
So we remove the files, and if there happens to be a crash at the right moment, it results in a database with a record in pg_database, but no directory/files? Is it possible to cancel the command half-way through, leaving the database in an essentially broken state (half the files exists, half is already deleted? > This could be fixed by doing DROP DATABASE the same way we do DROP > TABLE. At the DROP DATABASE command, just memorize the OID of the > dropped database, but don't delete anything yet. Perform the actual > deletion after flushing the commit record to disk. But then you would > have the opposite problem - you might be left with a database that's > dropped according to pg_database, but the files are still present on disk. I'm in favor of modifying DROP DATABASE so that it behaves like DROP TABLE. I find it more consistent (two DROP commands should not really do such wildly different things). ISTM this would allow us to remove the ForceSyncCommit(); and allow DROP DATABASE to be executed within a transaction (say, within a management script etc.). Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
