Re: foreign key locks, 2nd attempt

From: Jeroen Vermeulen <jtv(at)xs4all(dot)nl>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: foreign key locks, 2nd attempt
Date: 2012-02-24 09:38:52
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers
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!


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-02-24 10:01:13 Re: incompatible pointer types with newer zlib
Previous Message Dimitri Fontaine 2012-02-24 09:34:57 Re: Runtime SHAREDIR for testing CREATE EXTENSION