Re: DROP DATABASE vs patch to not remove files right away - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: DROP DATABASE vs patch to not remove files right away
Date
Msg-id 48065A85.1030103@enterprisedb.com
Whole thread Raw
In response to DROP DATABASE vs patch to not remove files right away  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: DROP DATABASE vs patch to not remove files right away  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Brendan Jurd"
Date:
Subject: Re: How to submit a patch
Next
From: "Merlin Moncure"
Date:
Subject: Re: How to submit a patch