Pavan Deolasee escribió:
> I'm trying to reason how this bug explains what we saw. In the test,
> we'd left with duplicate tuples. If I just take index 219 in the table
> as an example, that tuple had three duplicates. The tuple with CTID
> (150, 126) had the index pointer and the rest two were dangling tuples
> in the heap.
Hm, the examples I chased had t_infomask 0x2500, that is there were no
HOT bits set. It's quite possible that there's another bug in here, but
this one is a real one and it explains a very similar problem.
Now, how would your answers change if HeapTupleSatisfiesVacuum returned
RECENTLY_DEAD instead of DEAD? That's what I saw; and when it happened,
vacuum didn't set the "tupgone" flag, and thus passed the tuple to
heap_freeze_tuple; that routine examined the tuple and removed the Xmax
and set the HEAP_XMAX_INVALID bit because of the bogus logic. A tuple
which was supposed to be dead suddenly turned into visible.
I'm not really sure how these bogus conditions make HOT misbehave; I
don't fully understand the page pruning stuff. I think if they see a
chain and in the middle of it one Xmin doesn't match the next tuple's
Xmax, it considers the whole thing to not be a chain at all. So maybe
that explains the other effects?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services