Re: foreign key locks, 2nd attempt

On 2012-02-23 22:12, Noah Misch wrote:

> That alone would not simplify the patch much.  INSERT/UPDATE/DELETE on the
> foreign side would still need to take some kind of tuple lock on the primary
> side to prevent primary-side DELETE.  You then still face the complicated case
> of a tuple that's both locked and updated (non-key/immutable columns only).
> Updates that change keys are relatively straightforward, following what we
> already do today.  It's the non-key updates that complicate things.

Ah, so there's the technical hitch.  From previous discussion I was 
under the impression that:

1. Foreign-key updates only inherently conflict with _key_ updates on 
the foreign side, and that non-key updates on the foreign side were just 
caught in the locking cross-fire, so to speak.

And

2. The DELETE case was somehow trivially accounted for.  But, for 
instance, there does not seem to be a lighter lock type that DELETE 
conflicts with but UPDATE does not.  Bummer.


> By then, though, that change would share little or no code with the current
> patch.  It may have its own value, but it's not a means for carving a subset
> from the current patch.

No, to be clear, it was never meant to be.  Only a possible way to give 
users a way out of foreign-key locks more quickly.  Not a way to get 
some of the branch out to users more quickly.

At any rate, that seems to be moot then.  And to be honest, mechanisms 
designed for more than one purpose rarely pan out.

Thanks for explaining!


Jeroen