From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | MauMau <maumau307(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [bug fix] PITR corrupts the database cluster |
Date: | 2013-07-24 11:21:20 |
Message-ID: | 20130724112120.GD27288@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-07-24 12:59:43 +0200, Andres Freund wrote:
> > <Approach 2>
> > Like the DROP TABLE/INDEX case, piggyback the directory deletion record on
> > the transaction commit record, and eliminate the directory deletion record
> > altogether.
>
> I don't think burdening commit records with that makes sense. It's just
> not a common enough case.
>
> What we imo could do would be to drop the tablespaces in a *separate*
> transaction *after* the transaction that removed the pg_tablespace
> entry. Then an "incomplete actions" logic similar to btree and gin could
> be used to remove the database directory if we crashed between the two
> transactions.
>
> SO:
> TXN1 does:
> * remove catalog entries
> * drop buffers
> * XLogInsert(XLOG_DBASE_DROP_BEGIN)
>
> TXN2:
> * remove_dbtablespaces
> * XLogInsert(XLOG_DBASE_DROP_FINISH)
>
> The RM_DBASE_ID resource manager would then grow a rm_cleanup callback
> (which would perform TXN2 if we failed inbetween) and a
> rm_safe_restartpoint which would prevent restartpoints from occuring on
> standby between both.
>
> The same should probably done for CREATE DATABASE because that currently
> can result in partially copied databases lying around.
And CREATE/DROP TABLESPACE.
Not really related, but CREATE DATABASE's implementation makes me itch
everytime I read parts of it...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2013-07-24 11:35:49 | Re: Backup throttling |
Previous Message | Andres Freund | 2013-07-24 10:59:43 | Re: [bug fix] PITR corrupts the database cluster |