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
Tom Lane wrote:
> Bruce Momjian 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 metho
Bruce Momjian 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
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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
Tom Lane wrote:
> Bruce Momjian 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.
Lat
Bruce Momjian 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 wrote:
> Bruce Momjian 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-writabl
Bruce Momjian 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.
rega
Tom Lane wrote:
> "Federico Di Gregorio" <[EMAIL PROTECTED]> 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_coll
"Federico Di Gregorio" <[EMAIL PROTECTED]> 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 th
The following bug has been logged online:
Bug reference: 1707
Logged by: Federico Di Gregorio
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4.8
Operating system: Debian GNU/Linux
Description:statistics collector starts with stats_start_collector =
false
Detai
12 matches
Mail list logo
