Re: Fwd: question on foreign key lock - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Fwd: question on foreign key lock
Date
Msg-id CA+TgmoYp_UfVj392xkpeWCDiv4Ry0Jt30mgcNjSjtRABtCdK-A@mail.gmail.com
Whole thread Raw
In response to Fwd: question on foreign key lock  (Filip Rembiałkowski <filip.rembialkowski@gmail.com>)
Responses Re: Fwd: question on foreign key lock  (Filip Rembiałkowski <filip.rembialkowski@gmail.com>)
List pgsql-hackers
On Thu, Nov 8, 2012 at 3:45 AM, Filip Rembiałkowski
<filip.rembialkowski@gmail.com> wrote:
> maybe this is a better group for this question?
>
> I can't see why creating foreign key on table A referencing table B,
> generates an AccessExclusiveLock on B.
> It seems (to a layman :-) ) that only writes to B should be blocked.
>
> I'm really interested if this is either expected effect or any open TODO
> item or suboptimal behavior of postgres.

This comment explains it:
   /*    * Grab an exclusive lock on the pk table, so that someone doesn't delete    * rows out from under us.
(Althougha lesser lock would do for that    * purpose, we'll need exclusive lock anyway to add triggers to the pk    *
table;trying to start with a lesser lock will just create a risk of    * deadlock.)    */   pkrel =
heap_openrv(fkconstraint->pktable,AccessExclusiveLock); 

Concurrent DDL is something that's been discussed in detail on this
list in the past; unfortunately, there are some tricky race conditions
are the shared invalidation queue and SnapshotNow that make it hard to
implement properly.  I'm hoping to have some time to work on this at
some point, but it hasn't happened yet.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: TRUNCATE SERIALIZABLE and frozen COPY
Next
From: Robert Haas
Date:
Subject: Re: TRUNCATE SERIALIZABLE and frozen COPY