Re: can't stop autovacuum by HUP'ing the server

Dave Cramer wrote:
> On Tue, Aug 26, 2008 at 9:59 AM, Dave Cramer <pg@fastcrypt.com> wrote:
> 
> > On Tue, Aug 26, 2008 at 9:37 AM, Alvaro Herrera <
> > alvherre@commandprompt.com> wrote:

> >> Certainly not, and that's not what I see here either.  I assume process
> >> 25407 is (was) the postmaster, yes?
> >>
> >> If you "show autovacuum", is it on?
> >
> > Yes that was the postmaster, and I did check to see if autovacuum was on,
> > and it was not.
> >
> So where do we go from here ?

The only possible explanation for this behavior is that somebody is
signalling the postmaster due to Xid wraparound issues.  This is keyed
on some GUC vars -- Perhaps you have autovacuum_freeze_max_age set to an
insane value?

varsup.c line 246   /*      * We'll start trying to force autovacuums when oldest_datfrozenxid gets    * to be more
thanautovacuum_freeze_max_age transactions old.    *          * Note: guc.c ensures that autovacuum_freeze_max_age is
ina sane range,    * so that xidVacLimit will be well before xidWarnLimit.    *      * [...]    */        xidVacLimit =
oldest_datfrozenxid+ autovacuum_freeze_max_age;
 
   ...
   if (TransactionIdFollowsOrEquals(curXid, xidVacLimit) &&       IsUnderPostmaster)
SendPostmasterSignal(PMSIGNAL_START_AUTOVAC_LAUNCHER);



However, I think that in allowed configurations you should also receive
these warnings:
   /* Give an immediate warning if past the wrap warn point */   if (TransactionIdFollowsOrEquals(curXid,
xidWarnLimit))      ereport(WARNING,          (errmsg("database \"%s\" must be vacuumed within %u transactions",
         NameStr(*oldest_datname),                  xidWrapLimit - curXid),           errhint("To avoid a database
shutdown,execute a full-database VACUUM in \"%s\".",                   NameStr(*oldest_datname))));
 


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