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