Re: Enhancement to pg_dump

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!
>

In response to

Responses

Browse pgsql-hackers by date

  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