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

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)surnet(dot)cl>,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 12:09:47
Message-ID: 200506281209.j5SC9lD02383@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-patches
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.

Right.

> 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
> improvement.

No question.

> 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

Responses

pgsql-bugs by date

Next:From: Bobi IvanovDate: 2005-06-28 12:11:03
Subject: row number -1 is out of range 0..-1
Previous:From: Paolo PetranzanDate: 2005-06-28 11:34:42
Subject: BUG #1734: Can't install in D:\

pgsql-patches by date

Next:From: Petr JelinekDate: 2005-06-28 12:27:49
Subject: per user/database connections limit again
Previous:From: Dave PageDate: 2005-06-28 08:49:09
Subject: For review: Server instrumentation patch

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