Re: BUG #5326: The 2nd update of a table which has foreign keys is blocked.

Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> But to be exact, the comment says we *can* still skip the checks
> if we don't have any deferred FKs, right? If so, can we add
> a "has_deferred_FKs()" check to the condition?

> if ((!has_deferred_FKs(rel) ||
> !TransactionIdIsCurrentTransactionId(...)) &&
> RI_FKey_keyequal_upd_fk(...)

No. That wouldn't fix this problem (since the OP hasn't got any
deferred triggers) and it would break the test we need to make
(since the deferred FK isn't necessarily *this* FK, and even if
it was, what you propose would prevent it from being checked).

If we knew that the just-outdated tuple had been created by an update
that didn't change the FK columns, then we could skip applying the
check at the new update. But we don't know that, and I don't see any
real easy way to shoehorn in the knowledge. We don't have any extra
per-tuple state here --- and per-tuple state wouldn't be good enough
anyway, if there are multiple FKs. Another possibility is to chain
back to the latest tuple version that existed prior to this transaction
and compare FK columns against that version ... except we have no good
way to do that either; the t_ctid links point the wrong way.

AFAICS there is no simple way to improve this. It's an optimization
that the first update didn't block. We can't easily extend that
optimization to the second update. Sorry.

regards, tom lane