| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
| Cc: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, shridhar_daithankar(at)persistent(dot)co(dot)in, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: "truncate all"? |
| Date: | 2003-08-17 15:15:19 |
| Message-ID: | 11372.1061133319@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2003-08-17 15:22:50 | Re: compile error on cvs tip |
| Previous Message | Andrew Sullivan | 2003-08-17 15:06:19 | Re: [PERFORM] PostgreSQL vs. MySQL |