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 fail anyway? If it doesn't find one, wh
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 DEF
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 update/delete
> > checking the FK) the
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 update/delete
> checking the FK) the check is done with a SELECT ... FOR KEY SHARE.
> This makes per
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
