On Wed, Aug 25, 2010 at 6:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Well the alternative is teaching FKs how to handle locks. Ie, if you
could lock just certain columns of a row then heapam.c only needs to
check if those columns are being updated. It doesn't have to
understand why those columns are the ones that matter.
It's still not a very practical idea at least at first glance. It
would mean storing a variable sized list of columns somewhere that can
be consulted when the update happens. I don't know how the share lock
infrastructure works but I don't think it's obvious that there is such
a place.
> 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.
I think the above would solve that too. Since the FK trigger would
explicitly list the columns being referenced, dropping or adding an
index wouldn't change which columns were already locked in the rows
that were already looked up using the index.
--
greg