Drew Wilson <amw@speakeasy.net> writes:
> [ tip-of-tree fails on OS X with ]
> creating template1 database in data/base/1... Failed to initialize
> lc_monetaryFailed to initialize lc_numericFailed to initialize lc_timeok
> creating configuration files... ok
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?
regards, tom lane
