> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
>
> While chasing the VACUUM problem reported by Stephen Birch, I noticed
> something that looks like a potential trouble spot. Vacuum's initial
> scan routine, vc_scanheap, runs through the table to mark tuples as
> known committed or known dead, if possible (consulting the transaction
> log for tuples not yet so marked). It does the right things as far as
> marking committed/dead if it sees a tuple marked HEAP_MOVED_OFF or
> HEAP_MOVED_IN, which could only be there if a prior VACUUM failed
> partway through. But it doesn't *clear* those bits. Seems to me that
> that will screw up the subsequent vc_rpfheap procedure --- in
> particular, leaving a HEAP_MOVED_IN flag set will cause vc_rpfheap to
> complain (correctly!) about 'HEAP_MOVED_IN not expected', whereas
> leaving HEAP_MOVED_OFF set will confuse vc_rpfheap because it will
> think it moved the tuple itself.
>
I'm for your change.
Anyway it's not good to hold useless flags unnecessarily.
However I could hardly find the case that would cause a trouble.
It may occur in the following rare cases though I'm not sure.
HEAP_MOVED_OFF and (neither HEAP_XMIN_COMMITTED nor
HEAP_XMIN_INVALID) and the tuple was recently delete/updated.
This means that the previous VACUUM couldn't remove the tuple
because old transactions were running then and moreover the
VACUUM half successed(i.e aborted between internal commit and
external commit). Now VACUUM marks this tuple as tupgone once
but would turn it off later if old transctions are still running.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp