Re: autocommit vs TRUNCATE et al

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: autocommit vs TRUNCATE et al
Дата
Msg-id 15232.1034997953@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: autocommit vs TRUNCATE et al  (Gavin Sherry <swm@linuxworld.com.au>)
Ответы Re: autocommit vs TRUNCATE et al  (Lamar Owen <lamar.owen@wgcr.org>)
Список 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 по дате отправления:

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: ECPG and bison
Следующее
От: Tom Lane
Дата:
Сообщение: Re: /contrib/retep to gborg