Very Computer

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.

--

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

Quote: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).

Quote:> 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?

--

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

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.

Quote:

> > 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

  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Quote: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?

--

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

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

  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Quote: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.

--

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

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

---------------------------(end of broadcast)---------------------------

OK.

Quote:> 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

  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster