Re: Incomplete freezing when truncating a relation during vacuum

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Incomplete freezing when truncating a relation during vacuum
Дата
Msg-id 6692.1385936131@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Incomplete freezing when truncating a relation during vacuum  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Incomplete freezing when truncating a relation during vacuum
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> * Fix possible data corruptions due to incomplete vacuuming (Andres Freund, Heikki Linnakangas)

> Due to this bug (auto-)vacuum could sometimes treat a partial vacuum as
> a full table vacuum mistakenly increasing relfrozenxid as a result. This
> could happen if it managed to truncate the tail end of the table due to
> dead space. Possible consequences are:
> * Errors like "could not access status of transaction XXX" when
>   accessing such rows.
> * Vanishing rows after more than 2^31 transactions have passed.

Is there really a significant risk of clog access errors due to this bug?
IIUC, the risk is that tuples in pages that vacuum skips due to being
all-visible might not be frozen when intended.  But it seems just about
certain that such tuples would be properly hinted already, which means
that nothing would ever go to clog to confirm that.  So ISTM the only real
risk is that rows would become invisible after 2^31 transactions (and then
visible again after 2^31 more).

And even then you'd need persistent bad luck, in the form of incorrect
advancements of relfrozenxid having happened often enough to prevent any
anti-wraparound vacuums from getting launched.

Am I missing something?  It's certainly a bad bug, but it seems to me
that the probability of data loss is low enough that it's not so
surprising this has escaped detection for so long.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Incomplete freezing when truncating a relation during vacuum
Следующее
От: Piotr Marcinczyk
Дата:
Сообщение: Improve timestamp substraction to be DST-aware