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

From Tom Lane
Subject Re: autocommit vs TRUNCATE et al
Date
Msg-id 15232.1034997953@sss.pgh.pa.us
Whole thread Raw
In response to Re: autocommit vs TRUNCATE et al  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: autocommit vs TRUNCATE et al  (Lamar Owen <lamar.owen@wgcr.org>)
List pgsql-hackers
Gavin Sherry <swm@linuxworld.com.au> writes:
> On Fri, 18 Oct 2002, Tom Lane wrote:
>> Anyone see a way out of this catch-22?  If not, which is the least
>> bad alternative?

> Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial,
> I know :-).

I was about to say that the entire *point* of TRUNCATE is to be
transaction-unsafe ;-)

But on the other hand ... now that we have relation versioning (like
CLUSTER) it seems like TRUNCATE could generate new versions of the
relation and its indexes, without touching the originals.  This would
make it transaction-safe, at the cost of not releasing the original
version's disk space till you commit.  Seems like a good tradeoff to me.

It's not happening for 7.3, in any case, so we need a stopgap answer.
There are other examples --- CREATE/DROP DATABASE, for example ---
where we'd probably need an answer anyway; I doubt we'll ever make
those completely transaction-safe.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: ECPG and bison
Next
From: Tom Lane
Date:
Subject: Re: /contrib/retep to gborg