> 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? Regargs, Dmitry -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
