On 3/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Although this shouldn't happen anymore after fixing the chaining conditions, I'm inclined to introduce an additional test to verify that the starting tuple is actually MOVED_OFF after we finish the chain move. If not, give up on repair_frag the same as in some other corner cases.
scan_heap() would usually have collected the DEAD tuple in offsets_free list. How do you plan to check if the tuple is in middle on a chain which has RECENTLY_DEAD tuple before the tuple under check ? Don't we need to collect the TID of the DEAD tuple in the vtlinks[] as well to establish the backward chains ?
[ raised eyebrow... ] You sure about that? If you replace an XID before OldestXmin with one after, or vice versa, ISTM you *could* be creating a problem. "Committed" is not good enough. So it looks to me like you can't remove a DEAD tuple whose predecessor is only RECENTLY_DEAD.
I also thought about it. For HOT, since we are only talking about the HOT-update chain within the page, ISTM it should be OK to change the xmin of the next tuple. I can see the following two cases: Case 1: Say, OldestXmin = 17 10,20 20,18 18,16 16,14 14,22 22,0 RD RD D D RD L After we remove the two DEAD tuples, the HOT-chain would look like: 10,20 20,18 18,22 22,0 RD RD RD L Case 2: Say, OldestXmin = 17 10,20 20,18 18,16 16,14 14,0 RD RD D D L After we remove the two DEAD tuples, the HOT-chain would look like: 10,20 20,18 18,0 RD RD L In both the cases, the modified HOT-chain looks sane to me. I understand that when we walk backward in the chain, we would have "break" at the second last tuple in Case 1 and the last tuple in the Case 2, but with the modified chain we shall walk backward to the first tuple in the chain. Do you see any issue here ? Anyways, if you plan to fix the problem in a different way for the current implementation, I can use the same for HOT. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
