On Fri, Feb 8, 2013 at 10:08 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Alvaro Herrera escribió: >> Alvaro Herrera escribió: >> >> > Hm, if the foreign key patch is to blame, this sounds like these tuples >> > had a different set of XMAX hint bits and a different Xmax, and they >> > were clobbered by something like vacuum or page pruning. >> >> Hm, I think heap_freeze_tuple is busted, yes. > > This patch seems to fix the problem for me. Please confirm. >
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. I wonder how the index pointers to those tuples got removed: 1. May be HOT prune saw those tuples as DEAD and adjusted the HOT chain by removing those tuples. But then HOT prune would have reclaimed those tuples as well by setting the lp to UNUSED. 2. Index scan saw the HOT chain as DEAD and hence killed the index tuple. That looks unlikely because that would require an intermediate non-HOT update to the tuple. Given that the latest live tuple with the same index value is in the same block, I seriously doubt there was a non-HOT update to those tuples. Also, there are couple of other things to notice. 1. For VACUUM to freeze those tuples as you are suspecting, they should be seen as LIVE when HeapTupleSatisfiesVacuum is run by VACUUM. But for them to be removed from the HOT chain, they must be seen as DEAD to someone else and that must happen before VACUUM is run. 2. Tuple (150, 98) links to (150, 101) and both of them are unwanted duplicates. Can't reason how we end up in this state. Jeff mentioned that this thinks this issue could be reproducible without any crash recovery. Alvaro, I did not try to reproduce the problem using your patch, but can you please check if you see duplicates in similar state that we saw in Jeff's case ? Or can someone explain how we could end up in this state because of heap_tuple_freeze() freezing a potentially DEAD tuple ? Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
