Tuesday, August 26, 2008

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



On Tue, Aug 26, 2008 at 11:51 AM, Dave Cramer <pg@fastcrypt.com> wrote:


On Tue, Aug 26, 2008 at 11:41 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote:
Dave Cramer wrote:
> On Tue, Aug 26, 2008 at 10:56 AM, Alvaro Herrera <alvherre@commandprompt.com

> > 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?
>
> Doesn't appear to be insane ?
>
> #autovacuum_freeze_max_age = 200000000  # maximum XID age before forced
> vacuum

Not only sane, but also the default ;-)

What's the max age(pg_database.datfrozenxid)?

select datfrozenxid from pg_database ;
 datfrozenxid
--------------
    201850617
    101850961
     86039359
     21522712


this code in autovacuum.c looks like it might be interesting

                        if (AutoVacuumShmem->av_signal[AutoVacForkFailed])
                        {
                                /*
                                 * If the postmaster failed to start a new worker, we sleep
                                 * for a little while and resend the signal.  The new worker's
                                 * state is still in memory, so this is sufficient.  After
                                 * that, we restart the main loop.
                                 *
                                 * XXX should we put a limit to the number of times we retry?
                                 * I don't think it makes much sense, because a future start
                                 * of a worker will continue to fail in the same way.
                                 */
                                AutoVacuumShmem->av_signal[AutoVacForkFailed] = false;
                                pg_usleep(100000L);             /* 100ms */
                                SendPostmasterSignal(PMSIGNAL_START_AUTOVAC_WORKER);
                                continue;

Do these signals get cleaned up on a reload ?

Dave

No comments: