On Tue, Dec 21, 2004 at 10:54:27AM -0500, Tom Lane wrote:
> Patrick Hatcher <[EMAIL PROTECTED]> writes:
> > Curious: Why would a DELETE FROM tablename work while a pg_dump is
> > occurring but a TRUNCATE tablename will stay in a lock state until the
> > pg_dump is complete?
>
> TRUNCATE require
Hey there Tom thanks for the answer.
However, as you saw I wrote this early in the morning and forgot an
important piece of information:
The table at the time of the truncate was not being dumped. I could see
in pg_stat_activity that it was chugging away at one of the 63M row
tables I have.
Do
[EMAIL PROTECTED] (Patrick Hatcher) writes:
> Curious: Why would a DELETE FROM tablename work while a pg_dump is
> occurring but a TRUNCATE tablename will stay in a lock state until the
> pg_dump is complete?
DELETE FROM merely has to mark all the tuples as dead, which requires
no control over th
Patrick Hatcher <[EMAIL PROTECTED]> writes:
> Curious: Why would a DELETE FROM tablename work while a pg_dump is
> occurring but a TRUNCATE tablename will stay in a lock state until the
> pg_dump is complete?
TRUNCATE requires an exclusive lock on the table.
This is pretty much a no-free-lunch
Pg 7.4.5
Curious: Why would a DELETE FROM tablename work while a pg_dump is
occurring but a TRUNCATE tablename will stay in a lock state until the
pg_dump is complete?
About 60% of our tables are refreshed daily from our Filemaker database
and we don't care if one or more of these tables are e
