Skip site navigation (1) Skip section navigation (2)

Re: Referential Integrity and SHARE locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Csaba Nagy" <nagy(at)ecircle-ag(dot)com>, "Richard Huxton" <dev(at)archonet(dot)com>, "postgres hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Referential Integrity and SHARE locks
Date: 2007-02-02 21:50:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Fri, 2007-02-02 at 15:57 -0500, Tom Lane wrote:
>> , and it doesn't scale to
>> more than two holders, and I don't think it works for combinations of
>> share and exclusive lock.  Also, what happened to the third type of lock?

> Well, we just need to record the maximum two lock holders (given the
> semantics described). The third lock type is both locks at once.

You're not going to support shared locks?  That will be a big step
backwards ...

> Anyway, implementation aside, I wanted to agree the overall TODO, so we
> can think through the best way over a long period, if you agree in
> general.

No, I don't.  I think knowledge of which columns are in a PK is quite a
few levels away from the semantics of row locking.  To point out just
one problem, what happens when you add or drop a PK?  Or drop and
replace with a different column set?  Yes, I know dropping one requires
exclusive lock on the table, but the transaction doing it could hold row
locks within the table, and now it's very unclear what they mean.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-02-02 22:54:58
Subject: Re: Load distributed checkpoint
Previous:From: Tom LaneDate: 2007-02-02 21:36:52
Subject: Re: problem of geometric operator in v8.2.1

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group