Josh Berkus <josh@agliodbs.com> writes:
>> It strikes me that a possibly useful simplification of the idea is a
>> lock type that allows HOT updates and not non-HOT ones; or more
>> precisely not ones that change any indexed columns --- if the row ends
>> up having to go off-page for lack of space, that need not concern us.
> While an improvement over the current, that's still more restrictive
> than we actually need for FKs. FKs just need to lock the value of the
> reference column(s); they don't care if *other* indexes are updated.
That is true, but tracking exactly which indexes are relevant for that,
at the extremely low level that this would have to take effect, doesn't
seem like a bright plan to me. It's already ugly beyond words that
heapam.c knows enough about indexes to enforce the HOT restriction;
I do *not* want it having to know about FKs. There would also be new
locking restrictions added by the mere fact of trying to do that,
because DDL operations that previously didn't have to lock out SELECT
FOR SHARE now would. With Simon's patch that reduces ALTER TABLE ADD
FOREIGN KEY to not take AccessExclusiveLock, that's not a vacuous
concern anymore.
regards, tom lane