Re: [HACKERS] Concurrent VACUUM: first results - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Concurrent VACUUM: first results
Date
Msg-id 14679.943595754@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Concurrent VACUUM: first results  (Vadim Mikheev <vadim@krs.ru>)
Responses RE: [HACKERS] Concurrent VACUUM: first results  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Vadim Mikheev
Date:
Subject: Re: [GENERAL] drop/rename table and transactions
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] Concurrent VACUUM: first results