Re: Bug in VACUUM FULL ?

On 3/10/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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