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

On Tue, Aug 26, 2008 at 11:51 AM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:

>
>
> On Tue, Aug 26, 2008 at 11:41 AM, Alvaro Herrera <
> alvherre(at)commandprompt(dot)com> wrote:
>
>> Dave Cramer wrote:
>> > On Tue, Aug 26, 2008 at 10:56 AM, Alvaro Herrera <
>> alvherre(at)commandprompt(dot)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