Hi,
The fklocks patch moved HeapSatisfiesHOTandKeyUpdate (or rather
HeapSatisfiesHOTUpdate back then) to be called way earlier in
heap_update as its needed to know which lock level is
required. Unfortunately the oid of the new tuple isn't yet setup at that
point.
Due to this everytime there's an index on an oid - like in most catalog
tables - no HOT updates will be performed as the old tuples oid will be
compared to the new ones which isn't setup yet (so either InvalidOid or
uninitialized).
There's also a related bug which seems to go further back but has far
fewer implications, namely that the tableOid of the old tuple isn't
necessarily setup before determining HOTability. Now that only matters
if there's an index on 'tableoid' which doesn't seem to be an all that
frequent thing to do.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services