On 2013-12-01 17:15:31 -0500, Tom Lane wrote:
> 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).
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.
Thenext 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
