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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
