Wong, Yi Wen wrote:
> 2) Flip the order of HeapTupleHeaderIsHeapOnly(tuple) and HeapTupleHeaderIsHotUpdated(tuple). This is merely a
> microoptimization on a non-performance critical path because HeapOnly is a broader condititon than HotUpdated :-)
Actually, is this correct? AFAICS, IsHeapOnly refers to the *new*
version of the tuple in a HOT update, whereas IsHotUpdated refers to the
*old* version. We surely must never freeze a IsHotUpdated tuple
(because that would bring a dead tuple back to life, which is the bug at
hand), but what is the argument against freezing a IsHeapOnly tuple?
I think the way this test is written comes from some fuzzy thinking --
somebody (probably me) copied the test from lazy_scan_heap, but that
routine has two different reasons for each of those two conditions (one
is merely an optimization, the other is necessary for correctness). But
in the spot we're patching, one of them is wrong.
I could observe that this bug causes xids older than cutoff xid to
remain in xmax occasionally with that test in place. Removing the
"IsHeapOnly" part and keeping only IsHotUpdated makes that go away.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs