On 3/10/07, Tom Lane <tgl@sss.pgh.pa.us> 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
