Re: [HACKERS] Concurrent VACUUM: first results

Vadim Mikheev <vadim@krs.ru> writes:
>>>> * We have to commit our tuple' movings before we'll truncate
>>>> * relation, but we shouldn't lose our locks. And so - quick hack:

> ... or moved tuples may be lost in the case of DB/OS crash etc
>     that may occur after truncation but before commit...

I wonder whether there isn't a cleaner way to do this.  What about
removing this early commit, and doing everything else the way that
VACUUM does it, except that the physical truncate of the relation
file happens *after* the commit at the end of vc_vacone?

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?
        regards, tom lane