Re: [HACKERS] Concurrent VACUUM: first results

Tom Lane wrote:
> 
> While I'm asking silly questions: why does VACUUM relabel tuples
> with its own xact ID anyway?  I suppose that's intended to improve
> robustness in case of a crash --- but if there's a crash partway
> through VACUUM, it seems like data corruption is inevitable.  How
> can you pack tuples into the minimum number of pages without creating
> duplicate or missing tuples, if you are unlucky enough to crash before
> deleting the tuples from their original pages?

VACUUM:
1. has to preserve t_xmin/t_xmax in moved tuples
   (or MVCC will be broken) and so stores xid in t_cmin.
2. turns HEAP_XMIN_COMMITTED off in both tuple versions 
   (in old and new places).
3. sets HEAP_MOVED_IN in tuples in new places and
   HEAP_MOVED_OFF in tuples in old places.

Seeing HEAP_MOVED_IN/HEAP_MOVED_OFF (this is tested for
tuples with HEAP_XMIN_COMMITTED off only, just to don't
test in all cases) tqual.c funcs will check is tuple->t_cmin
committed or not - ie was VACUUM succeded in moving or not.
And so, single vacuum xid commit ensures that there will be
neither duplicates nor lost tuples.

Sorry, I should to describe this half year ago, but...

Vadim