| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Dmitry Fefelov <fozzy(at)ac-sw(dot)com> |
| Cc: | 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 11:29:36 |
| Message-ID: | AANLkTinkbEikDBhP28QryQp_rHgtbJ3rPIT82DemcxpE@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marko Tiikkaja | 2010-05-11 12:10:00 | Re: Partitioning/inherited tables vs FKs |
| Previous Message | Mike Fowler | 2010-05-11 09:21:43 | Re: Adding xpath_exists function |