From: | "Rob Kirkbride" <rob(dot)kirkbride(at)gmail(dot)com> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Richard Huxton" <dev(at)archonet(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enhancement to pg_dump |
Date: | 2008-11-26 12:56:52 |
Message-ID: | e0b3cb2b0811260456p5f5bc73cpd41081ccaf79dcb6@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)enterprisedb(dot)com>
> Rob Kirkbride <rob(dot)kirkbride(at)gmail(dot)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!
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-11-26 13:12:15 | Re: Visibility map, partial vacuums |
Previous Message | Gregory Stark | 2008-11-26 12:50:38 | Re: Enhancement to pg_dump |