On May 14, 2010, at 22:54 , Robert Haas wrote:
> On Thu, May 13, 2010 at 5:39 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Florian Pflug <f...@phlo.org> writes:
>>> All in all, I believe that SHARE and UPDATE row-level locks should be
>>> changed to cause concurrent UPDATEs to fail with a serialization
>>> error.
>> I don't see an argument for doing that for FOR SHARE locks, and it
>> already happens for FOR UPDATE (at least if the row actually gets
>> updated).  AFAICS this proposal mainly breaks things, in pursuit of
>> an unnecessary and probably-impossible-anyway goal of making FK locking
>> work with only user-level snapshots.
> After giving this considerable thought and testing the behavior at
> some length, I think the OP has it right.  One thing I sometimes need
> to do is denormalize a copy of a field, e.g.
> <snipped example>

I've whipped up a quick and still rather dirty patch that implements the 
behavior I proposed, at least for the case of conflicts between FOR UPDATE 
locks and updates. With the patch, any attempt to UPDATE or FOR UPDATE lock a 
row that has concurrently been FOR UPDATE locked will cause a serialization 
error. (The same for an actually updated row of course, but that happened 
before too).

While this part of the patch was fairly straight forward, make FOR SHARE 
conflict too seems to be much harder. The assumption that a lock becomes 
irrelevant after the transaction(s) that held it completely is built deeply 
into the multi xact machinery that powers SHARE locks. That machinery therefore 
assumes that once all members of a multi xact have completed the multi xact is 
dead also. But my proposal depends on a SERIALIZABLE transaction being able to 
find if any of the lockers of a row are invisible under it's snapshot - for 
which it'd need any multi xact containing invisible xids to outlive its 

best regards,
Florian Pflug

Attachment: serializable_share_lock.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to