Thread: Stats processor not restarting

I've noticed that if for example the autovacuum process dies (such as
with a kill -9 when testing my new shared mem implementation), only
autovac and bgwriter are restarted. The stats collector is terminated,
but not restarted. (Same goes for a regular backend, and not just
autovac)

Is there a reason for this, or is it a bug?

//Magnus

Magnus Hagander wrote:
> I've noticed that if for example the autovacuum process dies (such as
> with a kill -9 when testing my new shared mem implementation), only
> autovac and bgwriter are restarted. The stats collector is terminated,
> but not restarted. (Same goes for a regular backend, and not just
> autovac)
> 
> Is there a reason for this, or is it a bug?

I would say it is a bug, because the comments and code in ServerLoop()
and reaper() say different.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Tue, Mar 20, 2007 at 08:48:30AM -0400, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > I've noticed that if for example the autovacuum process dies (such as
> > with a kill -9 when testing my new shared mem implementation), only
> > autovac and bgwriter are restarted. The stats collector is terminated,
> > but not restarted. (Same goes for a regular backend, and not just
> > autovac)
> > 
> > Is there a reason for this, or is it a bug?
> 
> I would say it is a bug, because the comments and code in ServerLoop()
> and reaper() say different.

Bah, sorry about the noise. It was the effect of
PGSTAT_RESTART_INTERVAL.

Do we want to add some logging when we don't restart it due to repeated
failures?

//Magnus

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Magnus Hagander wrote:
>> I've noticed that if for example the autovacuum process dies (such as
>> with a kill -9 when testing my new shared mem implementation), only
>> autovac and bgwriter are restarted. The stats collector is terminated,
>> but not restarted. (Same goes for a regular backend, and not just
>> autovac)
>> 
>> Is there a reason for this, or is it a bug?

> I would say it is a bug, because the comments and code in ServerLoop()
> and reaper() say different.

There is code in pgstat_start that limits the frequency with which new
stats collectors can be spawned --- maybe your test case is hitting that?
        regards, tom lane

Magnus Hagander <magnus@hagander.net> writes:
> Bah, sorry about the noise. It was the effect of
> PGSTAT_RESTART_INTERVAL.
> Do we want to add some logging when we don't restart it due to repeated
> failures?

Not really, but maybe it would be sensible to reset last_pgstat_start_time
when doing a database-wide restart?  The motivation for the timeout was
to reduce cycle wastage if pgstat crashed by itself, but when you've
deliberately SIGQUITed it, that hardly seems to apply ...
        regards, tom lane