Re: FOR KEY LOCK foreign keys

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Subject: Re: FOR KEY LOCK foreign keys
Date: 2011-02-14 22:39:25
Message-ID: AANLkTimgf2OPZ8-25Q3_v+avF2fjcxVpyejSjm3_yuxr@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 11, 2011 at 09:13, Noah Misch <noah(at)leadboat(dot)com> wrote:
> The patch had a trivial conflict in planner.c, plus plenty of offsets.  I've
> attached the rebased patch that I used for review.  For anyone following along,
> all the interesting hunks touch heapam.c; the rest is largely mechanical.  A
> "diff -w" patch is also considerably easier to follow.

Here's a simple patch for the RelationGetIndexAttrBitmap() function,
as explained in my last post. I don't know if it's any help to you,
but since I wrote it I might as well send it up. This applies on top
of Noah's rebased patch.

I did some tests and it seems to work, although I also hit the same
visibility bug as Noah.

Test case I used:

THREAD A:
create table foo (pk int primary key, ak int);
create unique index on foo (ak) where ak != 0;
create unique index on foo ((-ak));

create table bar (foo_pk int references foo (pk));
insert into foo values(1,1);
begin; insert into bar values(1);

THREAD B:
begin; update foo set ak=2 where ak=1;

Regards,
Marti

Attachment Content-Type Size
0001-Only-acquire-KEY-LOCK-for-colums-that-can-be-referen.patch text/x-patch 5.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2011-02-14 22:45:07 tsearch Parser Hacking
Previous Message Andrew Dunstan 2011-02-14 22:29:09 Re: sepgsql contrib module