Обсуждение: 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