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 i
On Sat, Oct 11, 2014 at 1:32 AM, Tom Lane wrote:
> Nick Barnes 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 u
On Sat, Oct 11, 2014 at 5:01 AM, Adrian Klaver
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 fai
