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
