Thread: change name of redirect_stderr?
Before I wrap up the CSVlog stuff, we need to decide whether or not to change the name of the redirect_stderr setting, and if so to what. The reason is that with CSVlogs it will no longer apply just to stderr (we will require it to be on for CSVlogs, in fact). I suggest "redirect_logs", although it's arguably too general as it doesn't apply to syslog/eventlog. But maybe that doesn't matter, as we can note it in the docs and the sample conf file. thoughts? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Before I wrap up the CSVlog stuff, we need to decide whether or not to
> change the name of the redirect_stderr setting, and if so to what. The
> reason is that with CSVlogs it will no longer apply just to stderr (we
> will require it to be on for CSVlogs, in fact).
> I suggest "redirect_logs", although it's arguably too general as it
> doesn't apply to syslog/eventlog.
Perhaps it should be named analogously to stats_start_collector,
ie think of the syslogger process as a "log collector". I don't
much like "log_start_collector" though --- "start_log_collector"
seems far less confusing as to where the verb is.
No strong opinion here, just tossing out some ideas.
regards, tom lane
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> Before I wrap up the CSVlog stuff, we need to decide whether or not to >> change the name of the redirect_stderr setting, and if so to what. The >> reason is that with CSVlogs it will no longer apply just to stderr (we >> will require it to be on for CSVlogs, in fact). >> > > >> I suggest "redirect_logs", although it's arguably too general as it >> doesn't apply to syslog/eventlog. >> > > Perhaps it should be named analogously to stats_start_collector, > ie think of the syslogger process as a "log collector". I don't > much like "log_start_collector" though --- "start_log_collector" > seems far less confusing as to where the verb is. > > > Nobody else seems to care much. I'll go with "start_log_collector". cheers andrew
Andrew Dunstan wrote: > > > Tom Lane wrote: > > Andrew Dunstan <andrew@dunslane.net> writes: > > > >> Before I wrap up the CSVlog stuff, we need to decide whether or not to > >> change the name of the redirect_stderr setting, and if so to what. The > >> reason is that with CSVlogs it will no longer apply just to stderr (we > >> will require it to be on for CSVlogs, in fact). > >> > > > > > >> I suggest "redirect_logs", although it's arguably too general as it > >> doesn't apply to syslog/eventlog. > >> > > > > Perhaps it should be named analogously to stats_start_collector, > > ie think of the syslogger process as a "log collector". I don't > > much like "log_start_collector" though --- "start_log_collector" > > seems far less confusing as to where the verb is. > > > > > > > > Nobody else seems to care much. I'll go with "start_log_collector". Are we trying to use log_* prefixes, e.g. log_start_collector? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Andrew Dunstan wrote: > > > > >> I suggest "redirect_logs", although it's arguably too general as it > > >> doesn't apply to syslog/eventlog. > > > > > > Perhaps it should be named analogously to stats_start_collector, > > > ie think of the syslogger process as a "log collector". I don't > > > much like "log_start_collector" though --- "start_log_collector" > > > seems far less confusing as to where the verb is. > > > > Nobody else seems to care much. I'll go with "start_log_collector". > > Are we trying to use log_* prefixes, e.g. log_start_collector? That sounds like you want to log when the collector starts, which is not the case and is confusing -- what collector is it talking about? This is about starting the log collector. -- Alvaro Herrera http://www.PlanetPostgreSQL.org/ "How amazing is that? I call it a night and come back to find that a bug has been identified and patched while I sleep." (Robert Davidson) http://archives.postgresql.org/pgsql-sql/2006-03/msg00378.php
Alvaro Herrera wrote: > Bruce Momjian wrote: > > Andrew Dunstan wrote: > > > > > > >> I suggest "redirect_logs", although it's arguably too general as it > > > >> doesn't apply to syslog/eventlog. > > > > > > > > Perhaps it should be named analogously to stats_start_collector, > > > > ie think of the syslogger process as a "log collector". I don't > > > > much like "log_start_collector" though --- "start_log_collector" > > > > seems far less confusing as to where the verb is. > > > > > > Nobody else seems to care much. I'll go with "start_log_collector". > > > > Are we trying to use log_* prefixes, e.g. log_start_collector? > > That sounds like you want to log when the collector starts, which is not > the case and is confusing -- what collector is it talking about? This > is about starting the log collector. Yea, good point. I was just wondering because I don't see 'start' used in anywhere at the beginning of a GUC variable. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > Andrew Dunstan wrote: > > > > > > > > >> I suggest "redirect_logs", although it's arguably too general as it > > > > >> doesn't apply to syslog/eventlog. > > > > > > > > > > Perhaps it should be named analogously to stats_start_collector, > > > > > ie think of the syslogger process as a "log collector". I don't > > > > > much like "log_start_collector" though --- "start_log_collector" > > > > > seems far less confusing as to where the verb is. > > > > > > > > Nobody else seems to care much. I'll go with "start_log_collector". > > > > > > Are we trying to use log_* prefixes, e.g. log_start_collector? > > > > That sounds like you want to log when the collector starts, which is not > > the case and is confusing -- what collector is it talking about? This > > is about starting the log collector. > > Yea, good point. I was just wondering because I don't see 'start' used > in anywhere at the beginning of a GUC variable. Good point too. In other places we just name the feature that's to be started, for example we don't use "start_autovacuum". -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ "Granting software the freedom to evolve guarantees only different results, not better ones." (Zygo Blaxell)
Alvaro Herrera wrote: >>> That sounds like you want to log when the collector starts, which is not >>> the case and is confusing -- what collector is it talking about? This >>> is about starting the log collector. >>> >> Yea, good point. I was just wondering because I don't see 'start' used >> in anywhere at the beginning of a GUC variable. >> > > Good point too. In other places we just name the feature that's to be > started, for example we don't use "start_autovacuum". > > How about just "log_collector" then? Lets decide ASAP please - I want to get this committed. cheers andrew
Andrew Dunstan wrote: > > > Alvaro Herrera wrote: > >>> That sounds like you want to log when the collector starts, which is not > >>> the case and is confusing -- what collector is it talking about? This > >>> is about starting the log collector. > >>> > >> Yea, good point. I was just wondering because I don't see 'start' used > >> in anywhere at the beginning of a GUC variable. > >> > > > > Good point too. In other places we just name the feature that's to be > > started, for example we don't use "start_autovacuum". > > > > > > How about just "log_collector" then? > > Lets decide ASAP please - I want to get this committed. Works for me, or enable_log_collector? Based on Alvaro's comments, log_collector does sound like we are logging collector activity. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>>> On Tue, Aug 14, 2007 at 11:42 AM, in message <46C1DB5D.5000203@dunslane.net>, Andrew Dunstan <andrew@dunslane.net> wrote: > Alvaro Herrera wrote: >> In other places we just name the feature that's to be >> started, for example we don't use "start_autovacuum". > > How about just "log_collector" then? +1 Unambiguous and consistent with other settings. log_collector = on
Bruce Momjian wrote: > Andrew Dunstan wrote: > > > > > > Alvaro Herrera wrote: > > >>> That sounds like you want to log when the collector starts, which is not > > >>> the case and is confusing -- what collector is it talking about? This > > >>> is about starting the log collector. > > >>> > > >> Yea, good point. I was just wondering because I don't see 'start' used > > >> in anywhere at the beginning of a GUC variable. > > > > > > Good point too. In other places we just name the feature that's to be > > > started, for example we don't use "start_autovacuum". > > > > How about just "log_collector" then? > > > > Lets decide ASAP please - I want to get this committed. > > Works for me, or enable_log_collector? Based on Alvaro's comments, > log_collector does sound like we are logging collector activity. The problem here is that "log" seems to be a verb in "log_collector" which is what makes it confusing. So we need another verb to make it clear that "log" is not one. This is not a problem with "autovacuum" because that one cannot be confused with a verb. start_log_collector still gets my vote. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
> The problem here is that "log" seems to be a verb in "log_collector" > which is what makes it confusing. So we need another verb to make it > clear that "log" is not one. This is not a problem with "autovacuum" > because that one cannot be confused with a verb. > > start_log_collector still gets my vote. I vote against. Remember that some people look at the GUCs in alpha order from pg_settings. As such, if we're changing GUC names it ought to be in a way that groups logically if we can. log_collector_enable or log_collector_start or even log_redirect. But something with log_* -- Josh Berkus PostgreSQL @ Sun San Francisco
Josh Berkus <josh@agliodbs.com> writes:
>> The problem here is that "log" seems to be a verb in "log_collector"
>> which is what makes it confusing. So we need another verb to make it
>> clear that "log" is not one. This is not a problem with "autovacuum"
>> because that one cannot be confused with a verb.
>>
>> start_log_collector still gets my vote.
> log_collector_enable or log_collector_start or even log_redirect. But
> something with log_*
I'm voting with Alvaro on this. All of your suggestions are confusing
because "log" looks like the verb, which it is not. Specifically, they
sound like what the switch does is to cause a log message to be emitted
about some action that would occur anyway.
regards, tom lane
Josh Berkus wrote: >> The problem here is that "log" seems to be a verb in "log_collector" >> which is what makes it confusing. So we need another verb to make it >> clear that "log" is not one. This is not a problem with "autovacuum" >> because that one cannot be confused with a verb. >> >> start_log_collector still gets my vote. > > I vote against. Remember that some people look at the GUCs in alpha order > from pg_settings. As such, if we're changing GUC names it ought to be in a > way that groups logically if we can. Should we change the ordering of pg_settings? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Aug 14, 2007, at 12:40 , Tom Lane wrote: > Josh Berkus <josh@agliodbs.com> writes: >>> The problem here is that "log" seems to be a verb in "log_collector" >>> which is what makes it confusing. So we need another verb to >>> make it >>> clear that "log" is not one. This is not a problem with >>> "autovacuum" >>> because that one cannot be confused with a verb. >>> >>> start_log_collector still gets my vote. > >> log_collector_enable or log_collector_start or even log_redirect. >> But >> something with log_* > > I'm voting with Alvaro on this. All of your suggestions are confusing > because "log" looks like the verb, which it is not. Specifically, > they > sound like what the switch does is to cause a log message to be > emitted > about some action that would occur anyway. AIUI, if the-GUC-yet-to-be-named is not enabled, no logging is done at all: messages are just sent to stderr. Why something simple like enable_logging or start_logger? Michael Glaesemann grzm seespotcode net
Michael Glaesemann <grzm@seespotcode.net> writes:
> AIUI, if the-GUC-yet-to-be-named is not enabled, no logging is done
> at all: messages are just sent to stderr. Why something simple like
> enable_logging or start_logger?
Um, that's still logging by my definition. I could live with
"start_logger", since that is not the same as "logging".
It could be that if we want real consistency we're going to have to make
more changes than this one. Consider something like this:
* All variables that cause a specific kind of log message to be printed
or not shall be named "log_<something>". (So "log_" is a verb.)
* Variables that affect the logging mechanism as a whole shall be named
"logging_<something>".
For example, "log_line_prefix" is misnamed under this rule, and ought to
be "logging_line_prefix". Similarly, redirect_stderr would become
"logging_something" --- I'd prefer "logging_start_collector" but could
live with "logging_collector" (or maybe "logging_use_collector"?)
Looking at the docs, there are a whole bunch of GUCs that would have
to be renamed to meet this rule, but I think it would become clearer
what does what.
Is that too radical?
regards, tom lane
Heikki Linnakangas wrote: > Josh Berkus wrote: > >>> The problem here is that "log" seems to be a verb in "log_collector" >>> which is what makes it confusing. So we need another verb to make it >>> clear that "log" is not one. This is not a problem with "autovacuum" >>> because that one cannot be confused with a verb. >>> >>> start_log_collector still gets my vote. >>> >> I vote against. Remember that some people look at the GUCs in alpha order >> from pg_settings. As such, if we're changing GUC names it ought to be in a >> way that groups logically if we can. >> > > Should we change the ordering of pg_settings? > > Yeah, this is not a good reason for deciding a naming issue. If we really want thematic collection of GUC vars then we should arrange for some sort of hierarchical naming, and appropriate sectioning of the config file. cheers andrew
On 8/15/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > For example, "log_line_prefix" is misnamed under this rule, and ought to > be "logging_line_prefix". Similarly, redirect_stderr would become > "logging_something" --- I'd prefer "logging_start_collector" but could > live with "logging_collector" (or maybe "logging_use_collector"?) > The consistent prefix idea sounds good; does "logging_enable" jive with your proposal? Introduction of the term "collector" might be an overthink, and could confuse people. Your average postgres user tweaking his config file is going to see that and wonder what on earth a "log collector" is. Whereas it's generally understood that to "log" is to capture output and make it persistent, and "logging_enable" is clearly a setting that allows this to take place.
With so many people trying to paint this particular bikeshed, my suggestion to Andrew is to commit the patch as is and leave the rename for a later patch. -- Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J Jude: I wish humans laid eggs Ringlord: Why would you want humans to lay eggs? Jude: So I can eat them
"Brendan Jurd" <direvus@gmail.com> writes:
> On 8/15/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> For example, "log_line_prefix" is misnamed under this rule, and ought to
>> be "logging_line_prefix". Similarly, redirect_stderr would become
>> "logging_something" --- I'd prefer "logging_start_collector" but could
>> live with "logging_collector" (or maybe "logging_use_collector"?)
> The consistent prefix idea sounds good; does "logging_enable" jive
> with your proposal?
I dislike it. I claim that logging to plain stderr (without the
syslogger process) is still logging. Logging to syslog (which also
doen't need the syslogger process) is *definitely* logging. Something
named "logging_enable" would suggest to the normal person that without
it turned on, you'll get *nothing*.
I'm not wedded to "collector" per se, but you really cannot escape the
fact that there is one more concept in here than you wish to admit.
I think that reflecting the existence of a collector process in the GUC
names makes things clearer, not less clear.
regards, tom lane
On 8/15/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Brendan Jurd" <direvus@gmail.com> writes: > > The consistent prefix idea sounds good; does "logging_enable" jive > > with your proposal? > > I dislike it. I claim that logging to plain stderr (without the > syslogger process) is still logging. Logging to syslog (which also > doen't need the syslogger process) is *definitely* logging. Something > named "logging_enable" would suggest to the normal person that without > it turned on, you'll get *nothing*. > > I'm not wedded to "collector" per se, but you really cannot escape the > fact that there is one more concept in here than you wish to admit. > I think that reflecting the existence of a collector process in the GUC > names makes things clearer, not less clear. Fair enough. I just took a fresh look at postmaster.conf, and indeed the logging variables are more complex than I gave them credit for with "logging_enable". Retracted.
Heikki, > Should we change the ordering of pg_settings? Well, an unfixed issue in pg_settings is that the category/subcategory relationship got represented by a non-atomic field which makes sorting on that difficult. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
Tom Lane wrote: > "Brendan Jurd" <direvus@gmail.com> writes: > >> On 8/15/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >>> For example, "log_line_prefix" is misnamed under this rule, and ought to >>> be "logging_line_prefix". Similarly, redirect_stderr would become >>> "logging_something" --- I'd prefer "logging_start_collector" but could >>> live with "logging_collector" (or maybe "logging_use_collector"?) >>> > > >> The consistent prefix idea sounds good; does "logging_enable" jive >> with your proposal? >> > > I dislike it. I claim that logging to plain stderr (without the > syslogger process) is still logging. Logging to syslog (which also > doen't need the syslogger process) is *definitely* logging. Something > named "logging_enable" would suggest to the normal person that without > it turned on, you'll get *nothing*. > > I'm not wedded to "collector" per se, but you really cannot escape the > fact that there is one more concept in here than you wish to admit. > I think that reflecting the existence of a collector process in the GUC > names makes things clearer, not less clear. > > > Logging_collector won the day. I have just committed CSVlogs with that change. cheers andrew
On Aug 18, 2007, at 20:44 , Andrew Dunstan wrote: > Logging_collector won the day. I have just committed CSVlogs with > that change. Congrats! A couple last-minute correx: http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ func.sgml?r1=1.385&r2=1.386 s/log collector if running/log collector is running/ Might you want to use "logging collector" here, just to reinforce the term? http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ config.sgml?r1=1.137&r2=1.138 <varname>start_log_collector</varname> must be enabled to generate <varname>logging_collector</varname> must be enabled to generate Michael Glaesemann grzm seespotcode net
Michael Glaesemann wrote: > > On Aug 18, 2007, at 20:44 , Andrew Dunstan wrote: > >> Logging_collector won the day. I have just committed CSVlogs with >> that change. > > Congrats! > > A couple last-minute correx: > > thanks. fixed. cheers andrew