Re: [HACKERS] Stats processor not restarting
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 Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Stats processor not restarting
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Stats processor not restarting
Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Stats processor not restarting
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
