Thread: BUG #1707: statistics collector starts with stats_start_collector = false
BUG #1707: statistics collector starts with stats_start_collector = false
From
"Federico Di Gregorio"
Date:
The following bug has been logged online: Bug reference: 1707 Logged by: Federico Di Gregorio Email address: fog@initd.org PostgreSQL version: 7.4.8 Operating system: Debian GNU/Linux Description: statistics collector starts with stats_start_collector = false Details: If the following combinatio of parameters is used: stats_start_collector = false stats_row_level = true the collector process is started even if the documentation says that "The parameter stats_start_collector must be set to true for the statistics collector to be launched at all."
"Federico Di Gregorio" <fog@initd.org> writes:
> If the following combinatio of parameters is used:
> stats_start_collector = false
> stats_row_level = true
> the collector process is started even if the documentation says that "The
> parameter stats_start_collector must be set to true for the statistics
> collector to be launched at all."
I believe stats_start_collector is forced on if any of the subsidiary
parameters is set. Isn't that what you want?
regards, tom lane
Tom Lane wrote: > "Federico Di Gregorio" <fog@initd.org> writes: > > If the following combinatio of parameters is used: > > > stats_start_collector = false > > stats_row_level = true > > > the collector process is started even if the documentation says that "The > > parameter stats_start_collector must be set to true for the statistics > > collector to be launched at all." > > I believe stats_start_collector is forced on if any of the subsidiary > parameters is set. Isn't that what you want? If that is the logic, why do we have stats_start_collector at all? Seems we either should honor it, or remove it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> If that is the logic, why do we have stats_start_collector at all?
Ask Jan ;-)
I can see some advantage to it as a way of finding out whether the
collector was started or not ... but if that's the intent, we
should make it non user-writable.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > If that is the logic, why do we have stats_start_collector at all? > > Ask Jan ;-) > > I can see some advantage to it as a way of finding out whether the > collector was started or not ... but if that's the intent, we > should make it non user-writable. I can see someone turning it off but leaving other options on because they will want to turn them on later. I think our current behavior is broken. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I can see someone turning it off but leaving other options on because
> they will want to turn them on later.
"later" when? It's not useful to try to turn on stats_start_collector
after postmaster start, because the UDP socket won't exist.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I can see someone turning it off but leaving other options on because > > they will want to turn them on later. > > "later" when? It's not useful to try to turn on stats_start_collector > after postmaster start, because the UDP socket won't exist. Later such as in a later postmaster start, but personally I would just remove the option completely. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Later such as in a later postmaster start, but personally I would just
> remove the option completely.
I don't have a problem with removing it as a writable option ... but
I'm thinking we should leave it as a read-only GUC parameter (like
the several others we have already). Otherwise we'll need to add some
other method of finding out whether the collector is running.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Later such as in a later postmaster start, but personally I would just > > remove the option completely. > > I don't have a problem with removing it as a writable option ... but > I'm thinking we should leave it as a read-only GUC parameter (like > the several others we have already). Otherwise we'll need to add some > other method of finding out whether the collector is running. Why would a user care? They either are gathering such statistics, or they are not. I think the only issue is that you can't turn on certain options after postmaster start unless the stats collector is running --- is that the issue? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> I don't have a problem with removing it as a writable option ... but
>> I'm thinking we should leave it as a read-only GUC parameter (like
>> the several others we have already). Otherwise we'll need to add some
>> other method of finding out whether the collector is running.
> Why would a user care?
luser> It's not collecting statistics!
us> Is the collector running?
luser> How should I know?
us> er ...
If we don't have a way to check this, we'll regret it soon enough...
now maybe a GUC setting isn't the optimal way, but I think we need
*some* way besides ps. ps doesn't work remotely and I think there's
no simple equivalent under Windows either.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> I don't have a problem with removing it as a writable option ... but > >> I'm thinking we should leave it as a read-only GUC parameter (like > >> the several others we have already). Otherwise we'll need to add some > >> other method of finding out whether the collector is running. > > > Why would a user care? > > luser> It's not collecting statistics! > > us> Is the collector running? > > luser> How should I know? > > us> er ... > > If we don't have a way to check this, we'll regret it soon enough... > now maybe a GUC setting isn't the optimal way, but I think we need > *some* way besides ps. ps doesn't work remotely and I think there's > no simple equivalent under Windows either. Sure, but the GUC only reports that it thinks the stats collector started, not whether it is running or not. I think 'ps' is a fine way to tell. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: >> >>If we don't have a way to check this, we'll regret it soon enough... >>now maybe a GUC setting isn't the optimal way, but I think we need >>*some* way besides ps. ps doesn't work remotely and I think there's >>no simple equivalent under Windows either. > > > Sure, but the GUC only reports that it thinks the stats collector > started, not whether it is running or not. I think 'ps' is a fine way > to tell. Um, no such beast under win32. You can only see some postgres processes, but can't distinguish them. We'd need some functions that examine the pids known to the postmaster (pg_get_collector_pid, pg_get_logger_pid, ...) Regards, Andreas