Andreas 'ads' Scherbaum wrote:
> On Fri, 6 Jul 2007 11:30:19 +0530 Pavan Deolasee wrote:
> 
> Hello,
> 
> > On 7/5/07, Andreas 'ads' Scherbaum <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, 4 Jul 2007 18:04:35 -0400 Alvaro Herrera wrote:
> > >
> > > > Most likely it is worried about XID wraparound, and those are precisely
> > > > the tables that need urgent vacuumed because they haven't been vacuumed
> > > > in a long time.
> > >
> > > No, autovacuum is doing this with every run. Beside this, the database has
> > > only some 10k changes per day. The wraparound was my first idea, but i
> > > don't see a reason, why this should be happen with every autovacuum run.
> > >
> > Did you check freeze_max_age values in the pg_autovacuum table ? A very
> > small value can trigger XID wraparound related VACUUMs in every run.
> 
> The value is '0' for all columns in all entries, except 'vacrelid' and 
> 'enabled'.
> Can a VACUUM run happen, even if enabled is set to false?

Huh, try putting -1 in all columns instead.  0 is a nasty value to have
in there.  I haven't tested the effects but if freeze_max_age is 0 it
may be doing what Pavan says.

A fix is pending for out-of-range values in pg_autovacuum, per Galy Lee.
I should have worked harder at moving this stuff into
pg_class.reloptions, which would have meant less problems since there
would be no need to put values to those variables in the first place :-(
Sorry.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to