On Wed, Oct 22, 2014 at 3:19 AM, Kevin Grittner wrote:
>
> It doesn't seem like this analysis considers all of the available ON
> DELETE and ON UPDATE behaviors available. Besides RESTRICT there is
> CASCADE, SET NULL, SET DEFAULT, and NO ACTION. Some of those
> require updating the referencing
like a net win.
Not to mention the possibility of a deadlock, if the other transaction
updates our PK or adds another reference to it.
Thanks again,
Nick Barnes
One of the queries in ri_triggers.c has be a little baffled.
For (relatively) obvious reasons, a FK insert triggers a SELECT 1 FROM
pk_rel ... FOR KEY SHARE.
For not-so-obvious reasons, a PK delete triggers a SELECT 1 FROM fk_rel ...
FOR KEY SHARE.
I can't see what the lock on fk_rel achieves. Bo
