Tom Lane wrote:
> Actually, this entire thread is based on a misconception: the "bug"
> reporter was under the misimpression that the sum total of what the
> collector does is described by the three suboptions, and so having
> start_collector on without any of the suboptions on is a useless state.
> But this is not so. The collector tracks backend start/end in any case,
> and so you get a useful list of sessions in pg_stat_activity even
> without enabling any of the more expensive reporting options.
> So my vote at this point is that the code is not broken and we should
> not change it. Possibly the documentation could stand a little
> 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).
My issue is that we usually don't have GUC variables that can be set
automatically. Why can't we have the stats collector try to start, and
just throw a server log message if it fails. I guess I don't see why
that is worse than a GUC. Why is the stats collector unique in its use
of of the UDP resource? If we can't start IPv6 we just throw a server
log message and contiue, right?
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
In response to
pgsql-bugs by date
|Next:||From: Bobi Ivanov||Date: 2005-06-28 12:11:03|
|Subject: row number -1 is out of range 0..-1|
|Previous:||From: Paolo Petranzan||Date: 2005-06-28 11:34:42|
|Subject: BUG #1734: Can't install in D:\|
pgsql-patches by date
|Next:||From: Petr Jelinek||Date: 2005-06-28 12:27:49|
|Subject: per user/database connections limit again|
|Previous:||From: Dave Page||Date: 2005-06-28 08:49:09|
|Subject: For review: Server instrumentation patch|