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
