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
> Tatsuo, what is LC_ALL (or the other locale envvars) set to when you run
> the program? The man page for setlocale() on my machine documents that
> the main() starts in C or POSIX locale mode by default. The call to
> setlocale(LC_ALL, "") reads the envvars and sets the locale
> accordingly.
Lamar Owen writes:
> > I don't think so. On RH 6.1, strncmp() is the same it's ever been:
> [snip]
>
> Is that the code after any glibc RPM patches are applied?
Yes.
> I base my assertion on running test queries on a RedHat 6.1 box over a
> year ago, using the non-locale 6.5.3 RPMset I distrib
Peter Eisentraut wrote:
> Lamar Owen writes:
> > And building without locale support doesn't work, either, because, at
> > least on RH 6.1, strncmp() is buggered to use the locale's collation.
> I don't think so. On RH 6.1, strncmp() is the same it's ever been:
[snip]
Is that the code after any
Lamar Owen writes:
> And building without locale support doesn't work, either, because, at
> least on RH 6.1, strncmp() is buggered to use the locale's collation.
I don't think so. On RH 6.1, strncmp() is the same it's ever been:
int
strncmp (s1, s2, n)
const char *s1;
const char *s2
Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I know this is not PostgreSQL's fault but the broken locale data on
> > certain platforms. The problem makes it impossible to use PostgreSQL
> > RPMs in Japan.
> > I'm looking for solutions/workarounds for this problem.
> >> Build a s
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I know this is not PostgreSQL's fault but the broken locale data on
> certain platforms. The problem makes it impossible to use PostgreSQL
> RPMs in Japan.
>>
> I'm looking for solutions/workarounds for this problem.
>>
>> Build a set of RPMs without lo
Nathan Myers wrote:
>
> On Mon, Feb 12, 2001 at 09:59:37PM -0500, Tom Lane wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > I know this is not PostgreSQL's fault but the broken locale data on
> > > certain platforms. The problem makes it impossible to use PostgreSQL
> > > RPMs in Japan.
> > I know this is not PostgreSQL's fault but the broken locale data on
> > certain platforms. The problem makes it impossible to use PostgreSQL
> > RPMs in Japan.
>
> > I'm looking for solutions/workarounds for this problem.
>
> Build a set of RPMs without locale support?
>Run it with LC_ALL="
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I know this is not PostgreSQL's fault but the broken locale data on
> certain platforms. The problem makes it impossible to use PostgreSQL
> RPMs in Japan.
> I'm looking for solutions/workarounds for this problem.
Build a set of RPMs without locale supp
On Mon, Feb 12, 2001 at 09:59:37PM -0500, Tom Lane wrote:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I know this is not PostgreSQL's fault but the broken locale data on
> > certain platforms. The problem makes it impossible to use PostgreSQL
> > RPMs in Japan.
>
> > I'm looking for solutions/
23 matches
Mail list logo
