Thread: Locale support is now on by default
The determination of locale is now done as follows: collate/ctype: initdb --lc-collate, initdb --locale, LC_ALL, LC_COLLATE, LANG messages/monetary/numeric/time: Have GUC variables lc_messages, etc. The default is "", which means to inherit from the environment (or whatever setlocale() does with it). However, initdb will initialize postgresql.conf containing assignments to these variables determined as with collate/ctype above. So the "real" defaults are consistent with collate/ctype. initdb --no-locale is the same as initdb --locale=C, for convenience. Let's see if these rules end up making sense to everybody. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> The determination of locale is now done as follows:
> initdb --lc-collate, initdb --locale, LC_ALL, LC_COLLATE, LANG
> initdb --no-locale is the same as initdb --locale=C, for convenience.
I'm confused; what is the default behavior if you don't give any
switches to initdb?
BTW, something that's been bothering me for awhile is that the notice
we stuck into the backend a couple versions back (about "this locale
disables LIKE optimizations") is being hidden by initdb, because you
decided recently that it was okay to route all the backend's commentary
to /dev/null so as to hide xlog.c's startup chattiness. I don't object
to getting rid of that chattiness, but 2>/dev/null is throwing the baby
out with the bathwater (consider outright failure messages, for instance).
It might be that Bruce's recent changes to elog levels allow a graceful
compromise about backend messages during initdb. I haven't looked, but
maybe initdb could run the backend with message level one notch higher
than LOG to suppress all the normal-case messages without masking not-
so-normal cases.
regards, tom lane
Tom Lane writes: > > initdb --lc-collate, initdb --locale, LC_ALL, LC_COLLATE, LANG > > initdb --no-locale is the same as initdb --locale=C, for convenience. > > I'm confused; what is the default behavior if you don't give any > switches to initdb? Whatever is set in the environment -- which boils down to LC_ALL, LC_COLLATE, LANG. > It might be that Bruce's recent changes to elog levels allow a graceful > compromise about backend messages during initdb. I haven't looked, but > maybe initdb could run the backend with message level one notch higher > than LOG to suppress all the normal-case messages without masking not- > so-normal cases. I'll look. -- Peter Eisentraut peter_e@gmx.net
Tom Lane writes:
> It might be that Bruce's recent changes to elog levels allow a graceful
> compromise about backend messages during initdb. I haven't looked, but
> maybe initdb could run the backend with message level one notch higher
> than LOG to suppress all the normal-case messages without masking not-
> so-normal cases.
There doesn't seem to be a way to turn off LOG without hiding almost
everything:
if (lev == LOG || lev == COMMERROR){ if (server_min_messages == LOG) output_to_server = true; else if
(server_min_messages< FATAL) output_to_server = true;}
Everything except for PANIC is less than FATAL, so this doesn't make sense
to me.
Nonetheless, I don't like the way this message comes out. It destroys
the, er, well-formed display that initdb gives. Moreover, it's not really
a WARNING, meaning something is wrong. I was thinking about handling this
within initdb, with a display like this:
"""
The files belonging to this database system will be owned by user "peter".
This user must also own the server process.
Locale settings: collate=en_US ctype=en_US [...]
(This locale will prevent optimization of LIKE and regexp searches.)
creating directory pg-install/var/data... ok
creating directory pg-install/var/data/base... ok
[...]
"""
Yes, we'd need to duplicate some code within initdb, but it's not like
that list of LIKE-safe locales is very dynamic.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I was thinking about handling this
> within initdb, with a display like this:
> """
> The files belonging to this database system will be owned by user "peter".
> This user must also own the server process.
> Locale settings: collate=en_US ctype=en_US [...]
> (This locale will prevent optimization of LIKE and regexp searches.)
> creating directory pg-install/var/data... ok
> creating directory pg-install/var/data/base... ok
> [...]
> """
That works for me.
> Yes, we'd need to duplicate some code within initdb, but it's not like
> that list of LIKE-safe locales is very dynamic.
But removing the warning from xlog.c would be a Good Thing; it does not
belong there either, by any stretch of the imagination. As long as both
locale_is_like_safe() and initdb's list are commented with cross-links
to the other one, I don't think we're creating a huge maintenance
problem.
BTW, I still suggest changing initdb to set message_level = FATAL rather
than /dev/null'ing the output. Having to use -d to learn anything at
all about the cause of an initdb-time failure is a pain in the neck.
regards, tom lane
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > It might be that Bruce's recent changes to elog levels allow a graceful
> > compromise about backend messages during initdb. I haven't looked, but
> > maybe initdb could run the backend with message level one notch higher
> > than LOG to suppress all the normal-case messages without masking not-
> > so-normal cases.
>
> There doesn't seem to be a way to turn off LOG without hiding almost
> everything:
>
> if (lev == LOG || lev == COMMERROR)
> {
> if (server_min_messages == LOG)
> output_to_server = true;
> else if (server_min_messages < FATAL)
> output_to_server = true;
> }
>
> Everything except for PANIC is less than FATAL, so this doesn't make sense
> to me.
Actually, what this is saying is that for an elog(LOG) to show, the
server_min_messages, must be less than FATAL. Setting
server_min_messages to FATAL means only FATAL and PANIC appear:
Server levels are:
# debug5, debug4, debug3, debug2, debug1, # info, notice, warning, error, log, fatal, panic
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> BTW, I still suggest changing initdb to set message_level = FATAL rather > than /dev/null'ing the output. Having to use -d to learn anything at > all about the cause of an initdb-time failure is a pain in the neck. This is a great idea. Certainly there are FATAL/PANIC messages during initdb that could be helpful. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes:
> > There doesn't seem to be a way to turn off LOG without hiding almost
> > everything:
> >
> > if (lev == LOG || lev == COMMERROR)
> > {
> > if (server_min_messages == LOG)
> > output_to_server = true;
> > else if (server_min_messages < FATAL)
> > output_to_server = true;
> > }
> >
> > Everything except for PANIC is less than FATAL, so this doesn't make sense
> > to me.
>
> Actually, what this is saying is that for an elog(LOG) to show, the
> server_min_messages, must be less than FATAL.
I know what this is saying, but the coding is redundant (since LOG is also
less than FATAL).
> Setting server_min_messages to FATAL means only FATAL and PANIC
> appear:
>
> Server levels are:
>
> # debug5, debug4, debug3, debug2, debug1,
> # info, notice, warning, error, log, fatal, panic
I don't recall log being so high. Didn't it use to be after info?
Certainly there should be a way to see only warnings, errors, and higher
without seeing the "unimportant" log messages. Actually, I'm also
confused why we now have info, notice, *and* warning. Shouldn't two of
these be enough?
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > > There doesn't seem to be a way to turn off LOG without hiding almost
> > > everything:
> > >
> > > if (lev == LOG || lev == COMMERROR)
> > > {
> > > if (server_min_messages == LOG)
> > > output_to_server = true;
> > > else if (server_min_messages < FATAL)
> > > output_to_server = true;
> > > }
> > >
> > > Everything except for PANIC is less than FATAL, so this doesn't make sense
> > > to me.
> >
> > Actually, what this is saying is that for an elog(LOG) to show, the
> > server_min_messages, must be less than FATAL.
>
> I know what this is saying, but the coding is redundant (since LOG is also
> less than FATAL).
Sure, but the ordinal value of log is different for client and server:
#server_min_messages = notice # Values, in order of decreasing detail: # debug5,
debug4,debug3, debug2, debug1, # info, notice, warning, error, log, fatal,
# panic
#client_min_messages = notice # Values, in order of decreasing detail: # debug5,
debug4,debug3, debug2, debug1, # log, notice, warning, error
The LOG value is ordinally correct for CLIENT, but for SERVER, it is
just below FATAL. I can change it but for now that is what people
wanted, meaning you probably want LOG in the log file before WARNINGS or
even ERROR.
>
> > Setting server_min_messages to FATAL means only FATAL and PANIC
> > appear:
> >
> > Server levels are:
> >
> > # debug5, debug4, debug3, debug2, debug1,
> > # info, notice, warning, error, log, fatal, panic
>
> I don't recall log being so high. Didn't it use to be after info?
> Certainly there should be a way to see only warnings, errors, and higher
> without seeing the "unimportant" log messages. Actually, I'm also
> confused why we now have info, notice, *and* warning. Shouldn't two of
> these be enough?
We added NOTICE and INFO and WARNING because they were required. INFO
is for SET-like information, NOTICE is for non-warnings like sequence
creation for SERIAL, and WARNING is for real warnings like identifier
truncation.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Bruce Momjian writes: > > > Server levels are: > > > > > > # debug5, debug4, debug3, debug2, debug1, > > > # info, notice, warning, error, log, fatal, panic > > > > I don't recall log being so high. Didn't it use to be after info? > > Certainly there should be a way to see only warnings, errors, and higher > > without seeing the "unimportant" log messages. Actually, I'm also > > confused why we now have info, notice, *and* warning. Shouldn't two of > > these be enough? > > We added NOTICE and INFO and WARNING because they were required. INFO > is for SET-like information, NOTICE is for non-warnings like sequence > creation for SERIAL, and WARNING is for real warnings like identifier > truncation. OK, let me phrase my question clearly: How can I turn off LOG and turn on all errors in the server log? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > > > Server levels are: > > > > > > > > # debug5, debug4, debug3, debug2, debug1, > > > > # info, notice, warning, error, log, fatal, panic > > > > > > I don't recall log being so high. Didn't it use to be after info? > > > Certainly there should be a way to see only warnings, errors, and higher > > > without seeing the "unimportant" log messages. Actually, I'm also > > > confused why we now have info, notice, *and* warning. Shouldn't two of > > > these be enough? > > > > We added NOTICE and INFO and WARNING because they were required. INFO > > is for SET-like information, NOTICE is for non-warnings like sequence > > creation for SERIAL, and WARNING is for real warnings like identifier > > truncation. > > OK, let me phrase my question clearly: How can I turn off LOG and turn on > all errors in the server log? Right now, you can't. I originally had LOG next to INFO, and for server it was INFO, then LOG, and for client, it was LOG, then INFO, but someone suggested that LOG should be between ERROR and FATAL because most people want LOG stuff before they want to see ERROR/WARNING/NOTICE in the server logs. If you would prefer LOG down near INFO in the server message levels, please post the idea and let's get some more comments from folks. We thought about going with a bitwise capability where you could turn on different messages types independently, but the use of that with SET and the confusion hardly seemed worth it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes: > If you would prefer LOG down near INFO in the server message levels, > please post the idea and let's get some more comments from folks. LOG should be below WARNING, in any case. Perhaps between NOTICE and WARNING, but I'm not so sure about that. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> If you would prefer LOG down near INFO in the server message levels,
>> please post the idea and let's get some more comments from folks.
> LOG should be below WARNING, in any case. Perhaps between NOTICE and
> WARNING, but I'm not so sure about that.
I think the ordering Bruce developed is appropriate for logging.
There are good reasons to think that per-query ERRORs are less
interesting than LOG events for admin logging purposes.
The real problem here is that in the initdb context, we are really
dealing with an *interactive* situation, where LOG events ought to
be treated in the client-oriented scale --- but the backend does
not know this, it thinks it is emitting messages to the system log.
I'm thinking that the mistake is in hard-wiring one scale of message
interest to control the frontend output and another one to the "log"
(stderr/syslog) output. Perhaps we should have a notion of "interactive"
message priorities vs "logging" message priorities, and allow either
scale to be used to control which messages are dispatched to any
message destination.
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Bruce Momjian writes: > >> If you would prefer LOG down near INFO in the server message levels, > >> please post the idea and let's get some more comments from folks. > > > LOG should be below WARNING, in any case. Perhaps between NOTICE and > > WARNING, but I'm not so sure about that. > > I think the ordering Bruce developed is appropriate for logging. > There are good reasons to think that per-query ERRORs are less > interesting than LOG events for admin logging purposes. OK. > The real problem here is that in the initdb context, we are really > dealing with an *interactive* situation, where LOG events ought to > be treated in the client-oriented scale --- but the backend does > not know this, it thinks it is emitting messages to the system log. > > I'm thinking that the mistake is in hard-wiring one scale of message > interest to control the frontend output and another one to the "log" > (stderr/syslog) output. Perhaps we should have a notion of "interactive" > message priorities vs "logging" message priorities, and allow either > scale to be used to control which messages are dispatched to any > message destination. Can't we just 'grep -v '^LOG:' to remove the log display from initdb? Seems pretty simple. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026