Re: autocommit vs TRUNCATE et al - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: autocommit vs TRUNCATE et al
Date
Msg-id 200210221650.g9MGovq05833@candle.pha.pa.us
Whole thread Raw
In response to Re: autocommit vs TRUNCATE et al  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > I just noticed that this afternoon's changes cause dblink's regression
> > test to fail due to:
> 
> > CREATE OR REPLACE FUNCTION conditional_drop()
> > [...]
> >      IF FOUND THEN
> >          DROP DATABASE regression_slave;
> >      END IF;
> > [...]
> > ' LANGUAGE 'plpgsql';
> > SELECT conditional_drop();
> 
> > I'm wondering what is the best alternative?
> 
> Well, the *best* alternative would be to make CREATE/DROP DATABASE
> transaction-safe ;-).  I was speculating to myself earlier today about
> how we might do that.  It seems like it's not that far out of reach:
> we could make smgr's list of files-to-remove-at-xact-commit-or-abort
> include whole database subdirectories.  But I'm not sure how that would
> interact with upcoming features like tablespaces, so I don't want to
> go off and implement it right now.

FYI, the MSWin port in 7.4 will have C versions of 'cp' and 'rm -r', so
those can be used to hook into the smgr layer for all platforms.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_dump and large files - is this a problem?
Next
From: Kaare Rasmussen
Date:
Subject: Re: One 7.3 item left