Re: DROP DATABASE vs patch to not remove files right away

Tom Lane wrote:
> Actually ... what if the same DB OID and relfilenode get re-made before
> the checkpoint?  Then we'd be unlinking live data.  This is improbable
> but hardly less so than the scenario the PendingUnlinkEntry code was
> put in to prevent.
> 
> ISTM that we must fix the bgwriter so that ForgetDatabaseFsyncRequests
> causes PendingUnlinkEntrys for the doomed DB to be thrown away too.

Because of the asynchronous nature of ForgetDatabaseFsyncRequests, this 
still isn't enough, I'm afraid.

1. DROP TABLE footable;
2. Checkpoint begins.
3. DROP DATABASE foodb;
4. CREATE DATABASE bardb; -- bardb gets same OID as foodb, and a table 
copied from template database, let's call it bartable, gets same OID as 
footable
5. Checkpoint processes pending unlink for footable, but removes 
bartable instead

Needs more thought, after some sleep...

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com