Ian Westmacott <ianw@intellivid.com> writes:
> I imagine if a database's last process time is in the future, that would
> mess up autovacuum's choice algorithm (at the least). Can I confirm
> this is the problem? Is there a way to fix it short of dump/restore?
Hmm, that would explain a lot wouldn't it ... except that it looks to
me like your databases have old enough datvacuumxid to force vacuuming
regardless of last_autovac_time. So I'm not fully convinced.
AFAICS there is no convenient way in 8.1 to examine the per-database
last_autovac_time entries, which'd be needed to confirm this theory.
We should check that just to be sure. Please do the following:
1. Stop the postmaster.
2. Move the file $PGDATA/global/pgstat.stat somewhere else.
3. Restart the postmaster.
4. Send pgstat.stat as a binary attachment to me or Alvaro.
This will reset all your statistics counters and also the
last_autovac_time settings. If autovac starts to behave more
normally then we'll know that was it.
> I mentioned earlier that I had two installations like this. The second
> one doesn't seem to have any time issues. But in that case the only
> database being skipped is postgres. Do I need to worry about that?
Is the age() getting unreasonably large for postgres? It might be
skipping it because there's been no activity.
regards, tom lane