On Sat, Oct 11, 2014 at 5:01 AM, Adrian Klaver adrian.kla...@aklaver.com
wrote:
On 10/10/2014 10:41 AM, Nick Barnes wrote:
I understand why the FK insert needs to lock on the PK row. But why is
the PK delete trying to lock the FK row? If it finds one, won't the
delete fail anyway? If it
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
Nick Barnes nickbarne...@gmail.com writes:
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
On Sat, Oct 11, 2014 at 1:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Nick Barnes nickbarne...@gmail.com writes:
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
On 10/10/2014 10:41 AM, Nick Barnes wrote:
I understand why the FK insert needs to lock on the PK row. But why is
the PK delete trying to lock the FK row? If it finds one, won't the
delete fail anyway? If it doesn't find one, what is there to lock?
I would say this has to do with setting