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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
