Обсуждение: 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