| From: | Nick Barnes <nickbarnes01(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | FK check implementation |
| Date: | 2014-10-10 11:15:17 |
| Message-ID: | CAG+WGG=uN0SvSQ7qELOeFu2QzCrG+hEav_qbvOqJ9=W0xkfrJA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
I'm looking at the code behind the foreign key checks in ri_triggers.c, and
something's got me a little confused.
In both cases (FK insert/update checking the PK, and PK update/delete
checking the FK) the check is done with a SELECT ... FOR KEY SHARE.
This makes perfect sense for PK checks, but in the FK check, it seems
pointless at best; if it actually manages to find something to lock, it
will fail the check and error out moments later. And in any case, I don't
see how the key fields in the FK relation (to which the KEY SHARE lock
applies) are even relevant to the constraint in question.
What am I missing?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2014-10-10 13:38:02 | Re: PostgreSQL server won't start, corrupt? |
| Previous Message | Connor Wolf | 2014-10-10 07:03:56 | Re: [GENERAL] Understanding and implementing a GiST Index |