Re: "truncate all"?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "truncate all"?
Дата
Msg-id 11372.1061133319@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "truncate all"?  (Robert Treat <xzilla@users.sourceforge.net>)
Ответы Re: "truncate all"?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Robert Treat <xzilla@users.sourceforge.net> writes:
> On Sun, 2003-08-17 at 00:42, Tom Lane wrote:
>> To do anything else, you'd have to solve some locking and/or
>> race-condition problems: rows could be inserted in the other table
>> while the TRUNCATE runs.

> Seems like you'll have that issue with truncate all wont you? I guess
> we'll assume that if you use the cascade statement you understand these
> risks and accept them.

Yeah.  A TRUNCATE ALL would need exclusive lock on every table.  If
there are any other transactions running, the odds of getting all those
locks without deadlocking are pretty low.  TRUNCATE CASCADE would also
have a risk of failing due to deadlock (but with fewer tables in play
it'd have a smaller risk).  TRUNCATE RESTRICT should *not* create a
deadlock risk IMHO, and that means it can't lock other tables.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: ohp@pyrenet.fr
Дата:
Сообщение: Re: UnixWare on Current CVS: Success!
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: compile error on cvs tip