Skip site navigation (1) Skip section navigation (2)

Re: [BUGS] BUG #1707: statistics collector starts with stats_start_collector

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)surnet(dot)cl>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Federico Di Gregorio <fog(at)initd(dot)org>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [BUGS] BUG #1707: statistics collector starts with stats_start_collector
Date: 2005-06-28 06:05:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-patches
Alvaro Herrera <alvherre(at)surnet(dot)cl> writes:
> What about arranging postmaster's main loop so that it starts the stats
> collector process if one of the options is activated (assuming they were
> all off at start)?  Right now you have to restart the server, but I
> don't see why it has to be like that.

The reason for a restart is that what "stats_start_collector" is REALLY
all about is telling the postmaster whether to establish the loopback
UDP socket for stats messaging.  You don't get to add that after the
fact because there'd be no way to propagate the open socket into
existing backends.

And no, I wouldn't look with favor on the idea of creating the socket
unconditionally.  One of the reasons for wanting to be able to turn
off pgstats entirely is so that you aren't dead in the water if the
loopback UDP socket won't work for some reason (example: kernel packet
filtering that's not under your control).

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2005-06-28 06:16:31
Subject: Re: BUG #1733: Function visibility in transactions error
Previous:From: Tom LaneDate: 2005-06-28 02:39:55
Subject: Re: [BUGS] BUG #1707: statistics collector starts with stats_start_collector

pgsql-patches by date

Next:From: Fabien COELHODate: 2005-06-28 06:50:00
Subject: Re: Users/Groups -> Roles
Previous:From: Petr JelinekDate: 2005-06-28 05:47:45
Subject: Re: [PATCH] fix for pg_stat_database (numbackends is always

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group