From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bug in VACUUM FULL ? |
Date: | 2007-03-10 18:06:05 |
Message-ID: | 2e78013d0703101006p32cc5c08j88a8e275303e2cd9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2007-03-10 18:33:00 | Re: Bug in VACUUM FULL ? |
Previous Message | Tom Lane | 2007-03-10 17:36:58 | Re: what can be wrong? backport plpgpsm to 8.1 |