Re: Partitioning/inherited tables vs FKs
От | Robert Haas |
---|---|
Тема | Re: Partitioning/inherited tables vs FKs |
Дата | |
Msg-id | AANLkTinkbEikDBhP28QryQp_rHgtbJ3rPIT82DemcxpE@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Partitioning/inherited tables vs FKs (Dmitry Fefelov <fozzy@ac-sw.com>) |
Ответы |
Re: Partitioning/inherited tables vs FKs
SHARE locks vs. DELETE in SERIALIZABLE mode (Was: Partitioning/inherited tables vs FKs) |
Список | pgsql-hackers |
On Tue, May 11, 2010 at 2:16 AM, Dmitry Fefelov <fozzy@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
В списке pgsql-hackers по дате отправления: