change name of redirect_stderr?

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