Thread: initdb "Fails to initialize lc_time" (using 7.3.1)
I'm getting this error "Failed to initialize lc_time" back from initdb
when trying to init a data directory. I'm using the latest top-of-tree
CVS sources.
I get the same error, regardless of the locale parameter I pass to
initdb. (same error w/ "--no-locale" or "--locale en", etc.)
I'm building top-of-tree sources, on OSX (tried on both 10.1.5 and
10.2).
I didn't see any "no-locale" configure option.... Any other
suggestions?
Thanks,
Drew
The output from init message follows:
The files belonging to this database system will be owned by user
"drew".
This user must also own the server process.
The database cluster will be initialized with locale C.
creating directory data/postgres... ok
creating directory data/postgres/base... ok
creating directory data/postgres/global... ok
creating directory data/postgres/pg_xlog... ok
creating directory data/postgres/pg_clog... ok
creating template1 database in data/postgres/base/1... Failed to
initialize lc_timeok
creating configuration files... ok
initializing pg_shadow... Failed to initialize lc_timeok
enabling unlimited row size for system tables... Failed to initialize
lc_timeok
initializing pg_depend... Failed to initialize lc_timeok
creating system views... Failed to initialize lc_timeok
loading pg_description... Failed to initialize lc_timeok
creating conversions... Failed to initialize lc_timeok
setting privileges on built-in objects... Failed to initialize lc_timeok
vacuuming database template1... Failed to initialize lc_timeok
copying template1 to template0... Failed to initialize lc_timeok
Success. You can now start the database server using:
./bin/postmaster -D data/postgres
or
./bin/pg_ctl -D data/postgres -l logfile start
Drew Wilson <amw@speakeasy.net> writes:
> I'm getting this error "Failed to initialize lc_time" back from initdb
> when trying to init a data directory. I'm using the latest top-of-tree
> CVS sources.
Oh? Could we see the output from "env"? Also, what are your configure
options?
I have OS X 10.1 locally, and can try to reproduce it if you'll give
the environmental details ...
regards, tom lane
Thanks, Tom.
Here are my steps to reproduce. Using 7.3.1 top-of-tree, on MacOS X 10.1.5,
w/ Dev Tools April 2002 (gcc v2.95.2).
I ran the following:
0) cd pgsql
1) ./configure --prefix=/usr/local/pgsql --enable-multibyte
--enable-unicode-conversion --without-readline
2) make
3) make install
4) sudo mkdir /usr/local/pgsql/data
5) sudo chown drew /usr/local/pgsql/data
6) /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
and I get the following output from initdb:
The files belonging to this database system will be owned by user "drew".
This user must also own the server process.
The database cluster will be initialized with locale en_US.
This locale setting will prevent the use of indexes for pattern matching
operations. If that is a concern, rerun initdb with the collation order
set to "C". For more information see the Administrator's Guide.
Fixing permissions on existing directory data... ok
creating directory data/base... ok
creating directory data/global... ok
creating directory data/pg_xlog... ok
creating directory data/pg_clog... ok
creating template1 database in data/base/1... Failed to initialize
lc_monetaryFailed to initialize lc_numericFailed to initialize lc_timeok
creating configuration files... ok
initializing pg_shadow... Failed to initialize lc_monetaryFailed to
initialize lc_numericFailed to initialize lc_timeok
enabling unlimited row size for system tables... Failed to initialize
lc_monetaryFailed to initialize lc_numericFailed to initialize lc_timeok
initializing pg_depend... Failed to initialize lc_monetaryFailed to
initialize lc_numericFailed to initialize lc_timeok
creating system views... Failed to initialize lc_monetaryFailed to
initialize lc_numericFailed to initialize lc_timeok
loading pg_description... Failed to initialize lc_monetaryFailed to
initialize lc_numericFailed to initialize lc_timeok
creating conversions... Failed to initialize lc_monetaryFailed to
initialize lc_numericFailed to initialize lc_timeok
setting privileges on built-in objects... Failed to initialize
lc_monetaryFailed to initialize lc_numericFailed to initialize lc_timeok
vacuuming database template1... Failed to initialize lc_monetaryFailed to
initialize lc_numericFailed to initialize lc_timeok
copying template1 to template0... Failed to initialize lc_monetaryFailed
to initialize lc_numericFailed to initialize lc_timeok
Success. You can now start the database server using:
./bin/postmaster -D data
or
./bin/pg_ctl -D data -l logfile start
Oh, and bash tells me my ENV variables are:
bash-2.05$ export
declare -x CVSROOT=":pserver:amw@src.apple.com:cvs/repository"
declare -x CVS_RSH="ssh"
declare -x HOME="/Users/drew"
declare -x HOSTNAME="il0301a-dhcp125.apple.com"
declare -x HOSTTYPE="powerpc"
declare -x JAVA_HOME="/Library/Java/Home"
declare -x LANG="en_US"
declare -x MACHTYPE="powerpc-apple-darwin1.4"
declare -x OLDPWD="/Users/drew/tools/pgsql-7.3.1-latest"
declare -x OSTYPE="darwin1.4"
declare -x PAGER="less"
declare -x PATH="/usr/bin:/bin:/Users/drew:/Developer/Tools:/usr/local/bin:
/usr/local/sbin:/sbin:/usr/sbin"
declare -x PWD="/usr/local/pgsql"
declare -x SHELL="/bin/tcsh"
declare -x SHLVL="1"
declare -x TERM="vt100"
declare -x TERMCAP="d0|vt100|vt100-am|vt100am|dec vt100: :do=^J:co#
80:li#24:cl=\\E[;H\\E[2J:sf=2*\\ED:
:le=^H:bs:am:cm=5\\E[%i%d;%dH:nd=2\\E[C:up=2\\E[A: :ce=3\\E[K:cd=50\\E[J:
so=2\\E[7m:se=2\\E[m:us=2\\E[4m:ue=2\\E[m:
:md=2\\E[1m:mr=2\\E[7m:mb=2\\E[5m:me=2\\E[m: :rf=/usr/share/tabset/
vt100: :rs=\\E>\\E[?3l\\E[?4l\\E[?5l\\E[?7h\\E[?8h\\E[;r\\E[0m\\E(B\\E)
B\\E[2J: :ks=\\E[?1h\\E=:ke=\\E[?1l\\E>: :ku=\\EOA:kd=\\EOB:kr=\\EOC:kl=
\\EOD:kb=^H:
:ho=\\E[H:k1=\\EOP:k2=\\EOQ:k3=\\EOR:k4=\\EOS:pt:sr=2*\\EM:vt#3:xn:
:sc=\\E7:rc=\\E8:cs=\\E[%i%d;%dr:"
declare -x TERM_PROGRAM="Apple_Terminal"
declare -x TERM_PROGRAM_VERSION="57"
declare -x TOMCAT_HOME="/Users/drew/Applications/java/tomcat"
declare -x USER="drew"
declare -x __CF_USER_TEXT_ENCODING="0x1F5:0:0"
Thanks again,
Drew
On Tuesday, August 6, 2002, at 09:07 PM, Tom Lane wrote:
> Drew Wilson <amw@speakeasy.net> writes:
>> I'm getting this error "Failed to initialize lc_time" back from initdb
>> when trying to init a data directory. I'm using the latest top-of-tree
>> CVS sources.
>
> Oh? Could we see the output from "env"? Also, what are your configure
> options?
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
Tom Lane writes: > 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. We should probably catch this during initdb. Maybe I'll get to rewriting it in C and then we can share the routines. > 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? Generally, because there's no reason to, because we're only interested in collate and ctype. Specifically, if my environment is set to locale A and I initialize a cluster with locale B, I still want the possible error messages of "postgres -boot" to come out in locale A. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Specifically, if my environment is set to locale A and I initialize a
> cluster with locale B, I still want the possible error messages of
> "postgres -boot" to come out in locale A.
Even if that means you fail to detect that locale B is broken in some
way?
I'm not at all sure I buy this reasoning. If the user has told us a
locale to use on the initdb command line, seems to me he wants us to use
that locale, period.
regards, tom lane
Tom Lane writes: > Even if that means you fail to detect that locale B is broken in some > way? We don't pretend to do a thorough check of the locales anyway. We'd have to run a full test suite to do that. Of course, it would be nice to check whether setlocale() works, but initdb should do that itself then. > I'm not at all sure I buy this reasoning. If the user has told us a > locale to use on the initdb command line, seems to me he wants us to use > that locale, period. Think about it this way: If I'm the admin and a customer tells me to install a database for him in Greek, which localization would I want for responses from initdb? -- Peter Eisentraut peter_e@gmx.net
Tom Lane writes: > * 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. I've changed the assignments in main.c for MONETARY, NUMERIC, and TIME to "C". This should fix this issue without losing functionality, since we don't refer to these locales during startup. (The actual reason for this change is that of course we want to have these categories set to C later during backend operation -- see number format thread on -hackers. So this should conveniently take care of both.) -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Think about it this way: If I'm the admin and a customer tells me to
> install a database for him in Greek, which localization would I want for
> responses from initdb?
I see your point, but I'd *definitely* want initdb to tell me about it
if there were any problems with the locale name I'd entered. As it
stands, initdb goes out of its way to make sure that I won't know.
That's not an improvement ...
regards, tom lane