On 2013-12-01 17:15:31 -0500, Tom Lane wrote:
> Andres Freund <and...@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.  The next vacuum
         * will clean it up.
        if (!scan_all)

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.


Andres Freund

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to