From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, shridhar_daithankar(at)persistent(dot)co(dot)in, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: "truncate all"? |
Date: | 2003-08-24 22:57:08 |
Message-ID: | 200308242257.h7OMv8208148@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
TODO updated:
* Allow TRUNCATE ... CASCADE/RESTRICT
---------------------------------------------------------------------------
Tom Lane wrote:
> Robert Treat <xzilla(at)users(dot)sourceforge(dot)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
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-08-24 23:09:44 | I am back |
Previous Message | Tom Lane | 2003-08-24 22:39:18 | Re: Single-file DBs WAS: Need concrete 'Why Postgres |