Re: Bug in autovacuum.c?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in autovacuum.c?
Date: 2011-03-31 16:58:41
Message-ID: AANLkTimQX_ag=xt_6bO5sEbKmLn-RUWO3hSdr3uqesAJ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 31, 2011 at 12:17 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Looking over the autovacuum.c code, I see:
>
>    /*
>     * Determine the oldest datfrozenxid/relfrozenxid that we will allow to
>     * pass without forcing a vacuum.  (This limit can be tightened for
>     * particular tables, but not loosened.)
>     */
>    recentXid = ReadNewTransactionId();
>    xidForceLimit = recentXid - autovacuum_freeze_max_age;
>    /* ensure it's a "normal" XID, else TransactionIdPrecedes misbehaves */
>    if (xidForceLimit < FirstNormalTransactionId)
>        xidForceLimit -= FirstNormalTransactionId;
>
> This last line doesn't look right to me;  should it be:
>
>        xidForceLimit = FirstNormalTransactionId;

That would probably work, but the existing coding actually makes more
sense. It's essentially trying to scan backwards by
autovacuum_freeze_max_age XIDs through the circular XID space. But
the XID space isn't actually circular, because there are 3 special
values. So if we land on one of those values we want to skip backward
by 3. Here FirstNormalTransactionId doesn't represent itself, but
rather the number of special XIDs that exist.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2011-03-31 16:58:48 Re: [HACKERS] Date conversion using day of week
Previous Message Gurjeet Singh 2011-03-31 16:48:31 Re: Problem with pg_upgrade?