Re: Referential Integrity and SHARE locks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Referential Integrity and SHARE locks
Date
Msg-id 24539.1170453010@sss.pgh.pa.us
Whole thread Raw
In response to Re: Referential Integrity and SHARE locks  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Referential Integrity and SHARE locks  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: problem of geometric operator in v8.2.1
Next
From: Bruce Momjian
Date:
Subject: Re: Load distributed checkpoint