Re: initdb "Fails to initialize lc_time" (7.3.1 + Darwin)

Tom - thanks for your detailed reply.

Based on your investigation I found a work-around: unset $LANG before
calling initdb --no-locale.

With this work-around, everything appears to be start up correctly (at
least on my 10.1.x system.)

Is there anything I can do to help investigate further?

Thanks,

Drew


On Wednesday, August 7, 2002, at 11:04 AM, Tom Lane wrote:

> Yeah, I can reproduce that here.  And although initdb gets to
> completion, the postmaster won't start:
>
> FATAL:  invalid value for option 'LC_MONETARY': 'en_US'
>
> The trigger for this problem is that you have LANG = en_US in your
> environment, but it seems that OS X doesn't really support that setting
> fully.  At least setlocale() rejects it for the MONETARY, NUMERIC, and
> TIME categories.  This causes two problems:
>
> * guc.c's initialization of the LC_foo variables fails; this is
> harmless
> but produces annoying warnings on stderr.  (I've fixed the
> misformatting
> of those messages, at least.)  We could perhaps have the init-time
> values be "C" not "", but that would mean lack of localization of some
> startup error messages; I'd rather live with the warnings on
> misconfigured systems than lose functionality on correctly configured
> ones.
>
> * initdb puts LC_MONETARY = 'en_US', etc, into postgresql.conf, causing
> a FATAL error during postmaster startup when the assign_hook rejects
> the
> value.
>
> I am not sure if initdb can do much to detect and reject bad locale
> settings.  locale(1) is apparently not portable (at least I don't see
> it
> on my OS X system), and it's probably not worth compiling a test
> program
> to probe what setlocale() does.  Peter, any ideas?
>
> Also, although initdb --no-locale gets around the startup failure, you
> still see all the "Failed to initialize" chatter.  This is because
> initdb massages its own variables but doesn't unset LANG when you use
> that option.  Peter, why did you set up initdb's locale switches that
> way?  Why don't you have them set/unset the standard environment
> variable names, so that the effects are actually seen by programs
> called
> by initdb?