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: | 24539.1170453010@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-02-02 22:54:58 | Re: Load distributed checkpoint |
Previous Message | Tom Lane | 2007-02-02 21:36:52 | Re: problem of geometric operator in v8.2.1 |