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.


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!


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

Reply via email to