Re: Incomplete freezing when truncating a relation during vacuum - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Incomplete freezing when truncating a relation during vacuum
Date
Msg-id 6692.1385936131@sss.pgh.pa.us
Whole thread Raw
In response to Re: Incomplete freezing when truncating a relation during vacuum  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Incomplete freezing when truncating a relation during vacuum
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Incomplete freezing when truncating a relation during vacuum
Next
From: Piotr Marcinczyk
Date:
Subject: Improve timestamp substraction to be DST-aware