Re: foreign key locks, 2nd attempt - Mailing list pgsql-hackers

From Jeroen Vermeulen
Subject Re: foreign key locks, 2nd attempt
Date
Msg-id 4F463A4C.9000906@xs4all.nl
Whole thread Raw
In response to Re: foreign key locks, 2nd attempt  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: foreign key locks, 2nd attempt
Re: foreign key locks, 2nd attempt
List pgsql-hackers
On 2012-02-23 10:18, Simon Riggs wrote:

> However, review of such a large patch should not be simply pass or
> fail. We should be looking back at the original problem and ask
> ourselves whether some subset of the patch could solve a useful subset
> of the problem. For me, that seems quite likely and this is very
> definitely an important patch.
>
> Even if we can't solve some part of the problem we can at least commit
> some useful parts of infrastructure to allow later work to happen more
> smoothly and quickly.
>
> So please let's not focus on the 100%, lets focus on 80/20.

The suggested immutable-column constraint was meant as a potential 
"80/20 workaround."  Definitely not a full solution, helpful to some, 
probably easier to do.  I don't know if an immutable key would actually 
be enough to elide foreign-key locks though.

Simon, I think you had a reason why it couldn't work, but I didn't quite 
get your meaning and didn't want to distract things further at that 
stage.  You wrote that it "doesn't do what KEY LOCKS are designed to 
do"...  any chance you might recall what the problem was?

I don't mean to be pushy about my pet idea, and heaven knows I don't 
have time to implement it, but it'd be good to know whether I should put 
the whole thought to rest.


Jeroen


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: pg_stat_statements normalization: re-review
Next
From: Simon Riggs
Date:
Subject: Re: foreign key locks, 2nd attempt