From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Ian Westmacott <ianw(at)intellivid(dot)com>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: 8.1.8 autovacuum missing databases |
Date: | 2008-05-02 16:40:58 |
Message-ID: | 7391.1209746458@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I'm wondering if there could be a hidden bug in the age arithmetic
> somehow -- say because it's using unsigned comparison of signed
> variables, or the Max() macro is flawed, or something weird like that.
Umm ... actually, there's a bug in the hand calculations I did at the
start of this thread. The threshold that 8.1 uses is
(int32) ((MaxTransactionId >> 3) * 3 - 100000)
which works out to 1610512733, which is considerably more than the 300M
or so age() values that Ian is showing. I had somehow convinced myself
that it was less and he should be getting whole-db vacuums, but in
reality he shouldn't yet. It's only in 8.2 and up that we have a much
smaller threshold for trying to advance datfrozenxid.
So actually, what we are looking at is the not-whole-db logic, and
it's working exactly as designed. The only unexpected behavior was
the choice not to vacuum some of the DBs, which we now know is explained
by their having a last_autovac_time in the future.
Perhaps it is worth adding a defense to autovac to not believe last
autovac times that are in the future, since the system clock is not
under our control and could go backwards. Other than that I don't
think there's any bug here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-02 16:45:07 | Re: 8.1.8 autovacuum missing databases |
Previous Message | Darren Reed | 2008-05-02 08:59:29 | Re: Bus error in postgres 8.3 |