Skip site navigation (1) Skip section navigation (2)

Re: foreign key locks, 2nd attempt

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Jeroen Vermeulen <jtv(at)xs4all(dot)nl>
Cc: Noah Misch <noah(at)leadboat(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-23 14:21:39
Message-ID: CA+U5nMJY0Mc7wmyVjR9AEr0mrb473e+5Rmhi+RDOWMRq-qA8zg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Feb 23, 2012 at 1:08 PM, Jeroen Vermeulen <jtv(at)xs4all(dot)nl> wrote:

> 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?

The IMMUTABLE idea would work, but it requires all users to recode
their apps. By the time they've done that we'll have probably fixed
the problem in full anyway, so then we have to ask them to stop again,
which is hard so we'll be stuck with a performance tweak that applies
to just one release. So its the fully automatic solution we're looking
for. I don't object to someone implementing IMMUTABLE, I'm just saying
its not a way to get this patch simpler and therefore acceptable.

If people are willing to recode apps to avoid this then hire me and
I'll tell you how ;-)

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-02-23 14:41:42
Subject: Re: overriding current_timestamp
Previous:From: Simon RiggsDate: 2012-02-23 14:15:45
Subject: Re: foreign key locks, 2nd attempt

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group