Re: Enhancement to pg_dump - Mailing list pgsql-hackers

From Rob Kirkbride
Subject Re: Enhancement to pg_dump
Date
Msg-id e0b3cb2b0811260456p5f5bc73cpd41081ccaf79dcb6@mail.gmail.com
Whole thread Raw
In response to Re: Enhancement to pg_dump  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Enhancement to pg_dump
List pgsql-hackers
I must admit I've not read up on the various locks that are set so that's a good point. Is there a good reference for me to read and understand these?

I'm guessing though that a delete from and then an insert never requires an exclusive lock, what about adding/deleting constraints?

Rob



2008/11/26 Gregory Stark <stark@enterprisedb.com>
Rob Kirkbride <rob.kirkbride@gmail.com> writes:

> Richard,
>
> Yes, I've changed it use TRUNCATE rather than DELETE and it's working well for
> us now.

I'm a bit surprised actually as it sounded like you were aiming to avoid the
table lock. A TRUNCATE does require an exclusive lock on the table. It still
has advantages over DROP in that there is no window when the table does not
exist and any existing references to the table from views or functions will
continue to function.


--
 Gregory Stark
 EnterpriseDB          http://www.enterprisedb.com
 Ask me about EnterpriseDB's RemoteDBA services!

pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Enhancement to pg_dump
Next
From: Tom Lane
Date:
Subject: Re: Visibility map, partial vacuums