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

Re: foreign key locks

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Erik Rijkers <er(at)xs4all(dot)nl>
Cc: Kevin Grittner <kgrittn(at)mail(dot)com>, pgsql-hackers(at)postgresql(dot)org,Andres Freund <andres(at)2ndquadrant(dot)com>
Subject: Re: foreign key locks
Date: 2013-01-10 21:00:40
Message-ID: 20130110210040.GB4110@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Here's version 28 of this patch.  The only substantive change here from
v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive
or LockTupleNoKeyExclusive, depending on whether the key columns are
being modified by the update.  This needs to go through EvalPlanQual, so
that function is now getting the lock mode as a parameter instead of
hardcoded LockTupleExclusive.  (All other users of GetTupleForTrigger
still use LockTupleExclusive, so there's no change for anybody other
than FOR EACH ROW BEFORE UPDATE triggers).

At this point, I think I've done all I wanted to do in connection with
this patch, and I intend to commit.  I think this is a good time to get
it committed, so that people can play with it more extensively and
report any breakage I might have caused before we even get into beta.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment: fklocks-28.patch.gz
Description: application/octet-stream (99.1 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2013-01-10 21:18:31
Subject: Re: PL/perl should fail on configure, not make
Previous:From: Tom LaneDate: 2013-01-10 20:13:20
Subject: Re: Reducing size of WAL record headers

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