Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> 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 betwee
Peter Eisentraut <[EMAIL PROTECTED]> 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
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 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 i
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
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 = tru
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
> 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 t
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
Peter Eisentraut <[EMAIL PROTECTED]> 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_
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
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 boi
Peter Eisentraut <[EMAIL PROTECTED]> 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
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 w
14 matches
Mail list logo
