Re: [HACKERS] Concurrent VACUUM: first results

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Concurrent VACUUM: first results
Дата
Msg-id 14679.943595754@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Concurrent VACUUM: first results  (Vadim Mikheev <vadim@krs.ru>)
Ответы RE: [HACKERS] Concurrent VACUUM: first results  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Vadim Mikheev
Дата:
Сообщение: Re: [GENERAL] drop/rename table and transactions
Следующее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: [HACKERS] Concurrent VACUUM: first results