Re: Incomplete freezing when truncating a relation during vacuum

On 2013-12-01 17:15:31 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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).

Unfortunately it's not actually too hard to hit due to following part of the
code in vacuumlazy.c:

/* We need buffer cleanup lock so that we can prune HOT chains. */
if (!ConditionalLockBufferForCleanup(buf))
{
/*
* If we're not scanning the whole relation to guard against XID
* wraparound, it's OK to skip vacuuming a page. The next vacuum
* will clean it up.
*/
if (!scan_all)
{
ReleaseBuffer(buf);
continue;
}
...

if you have some concurrency you hit that path pretty often. And once
such a vacuum went through the table it will have a higher relfrozenxid,
so an impending "wave" of anti-wraparound vacuums won't scan it.

Also, the hint bits won't be on potential standbys, so that's not
necessarily preventing problems.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services