From: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dmitry Fefelov <fozzy(at)ac-sw(dot)com>, pgsql-hackers(at)postgresql(dot)org, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Sándor Miglécz <sandor(at)cybertec(dot)at>, Hans-Juergen Schoenig <hs(at)cybertec(dot)at> |
Subject: | Re: Partitioning/inherited tables vs FKs |
Date: | 2010-05-11 12:10:00 |
Message-ID: | 4BE94918.6080809@cs.helsinki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2010-05-11 14:29 +0200, Robert Haas wrote:
> On Tue, May 11, 2010 at 2:16 AM, Dmitry Fefelov <fozzy(at)ac-sw(dot)com> wrote:
>>> The referential integrity triggers contain some extra magic that isn't
>>> easily simulatable in userland, and that is necessary to make the
>>> foreign key constraints airtight. We've discussed this previously but
>>> I don't remember which thread it was or the details of when things
>>> blow up. I think it's something like this: the parent has a tuple
>>> that is not referenced by any child. Transaction 1 begins, deletes
>>> the parent tuple (checking that it has no children), and pauses.
>>> Transaction 2 begins, adds a child tuple that references the parent
>>> tuple (checking that the parent exists, which it does), and commits.
>>> Transaction 1 commits.
>>
>> Will SELECT ... FOR SHARE not help?
>
> Try it, with the example above. I think you'll find that it doesn't.
TXA => delete from foo;
DELETE 1
TXB => select a from foo for share; -- waits
What am I missing?
Regards,
Marko Tiikkaja
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolas Barbier | 2010-05-11 12:55:12 | Re: Partitioning/inherited tables vs FKs |
Previous Message | Robert Haas | 2010-05-11 11:29:36 | Re: Partitioning/inherited tables vs FKs |