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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
