On 2010-05-11 14:29 +0200, Robert Haas wrote: > On Tue, May 11, 2010 at 2:16 AM, Dmitry Fefelov <fo...@ac-sw.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
