Thread: initdb failure in CVS
I am seeing the following failure of initdb in CVS:The files belonging to this database system will be owned by user "postgres".Thisuser must also own the server process.The database cluster will be initialized with locale C.creating directory/u/pg/data ... okcreating directory /u/pg/data/global ... okcreating directory /u/pg/data/pg_xlog ... okcreatingdirectory /u/pg/data/pg_clog ... okcreating directory /u/pg/data/base ... okcreating directory /u/pg/data/base/1... okselecting default max_connections ... 100selecting default shared_buffers ... 1000creating configurationfiles ... ok creating template1 database in /u/pg/data/base/1 ... FATAL: invalid value for parameter "client_encoding": "" initdb: child process exited with exit code 1initdb: failedinitdb: removing data directory "/u/pg/data" The problem seems to be related to a commit made to initdb a few days ago. revision 1.24date: 2004/05/05 16:09:31; author: tgl; state: Exp; lines: +23 -2Use a more portable technique for unsettingenvironment variables,and unset PGCLIENTENCODING to prevent backend from dying if it's setto something incompatiblewith the -E option. I don't have any encoding set in my system. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am seeing the following failure of initdb in CVS:
> FATAL: invalid value for parameter "client_encoding": ""
Hmm. Apparently the pg_unsetenv routine I put into initdb.c doesn't
work on your platform. Which is odd, because we've used exactly the
same technique to unset TZ in variable.c for years and years, and not
had any reports of trouble.
We might have to put configure to work to figure out how to do unsetenv
properly. Any thoughts?
regards, tom lane
Bruce Momjian wrote:
>I am seeing the following failure of initdb in CVS:
>
> The files belonging to this database system will be owned by user "postgres".
> This user must also own the server process.
>
> The database cluster will be initialized with locale C.
>
> creating directory /u/pg/data ... ok
> creating directory /u/pg/data/global ... ok
> creating directory /u/pg/data/pg_xlog ... ok
> creating directory /u/pg/data/pg_clog ... ok
> creating directory /u/pg/data/base ... ok
> creating directory /u/pg/data/base/1 ... ok
> selecting default max_connections ... 100
> selecting default shared_buffers ... 1000
> creating configuration files ... ok
>
> creating template1 database in /u/pg/data/base/1 ...
>
> FATAL: invalid value for parameter "client_encoding": ""
>
> initdb: child process exited with exit code 1
> initdb: failed
> initdb: removing data directory "/u/pg/data"
>
>The problem seems to be related to a commit made to initdb a few days
>ago.
>
> revision 1.24
> date: 2004/05/05 16:09:31; author: tgl; state: Exp; lines: +23 -2
> Use a more portable technique for unsetting environment variables,
> and unset PGCLIENTENCODING to prevent backend from dying if it's set
> to something incompatible with the -E option.
>
>I don't have any encoding set in my system.
>
>
>
The change is based on this code from here (backend/commands/variable.c):
/*
* unsetenv() works fine, but is BSD, not POSIX, and is not available
* under Solaris, among others. Apparently putenv() called as below
* clears the process-specific environment variables. Other
* reasonable arguments to putenv() (e.g. "TZ=", "TZ", "") result in a
* core dump (under Linux anyway). - thomas 1998-01-26
*/
if (tzbuf[0] == 'T')
{
strcpy(tzbuf, "=");
if (putenv(tzbuf) != 0)
elog(LOG, "could not clear TZ environment variable");
tzset();
}
The Linux man page for putenv says this:
Description for libc4, libc5, glibc: If the argument string is of the
form name, and does not contain an ‘=’ character, then the variable
name is removed from the environment. If putenv() has to allocate a
new array environ, and the previous array was also allocated by
putenv(), then it will be freed. In no case will the old storage asso-
ciated to the environment variable itself be freed.
The libc4 and libc5 and glibc 2.1.2 versions conform to SUSv2: the
pointer string given to putenv() is used. In particular, this string
becomes part of the environment; changing it later will change the
environment. (Thus, it is an error is to call putenv() with an auto-
matic variable as the argument, then return from the calling function
while string is still part of the environment.) However, glibc
2.0-2.1.1 differs: a copy of the string is used. On the one hand this
causes a memory leak, and on the other hand it violates SUSv2. This has
been fixed in glibc2.1.2.
The BSD4.4 version, like glibc 2.0, uses a copy.
I suspect you have seen this latter effect, i.e. it in effect did
putenv("PGCLIENTENCODING=");
putenv("=");
leaving you with an empty string as the env value rather than unsetting it.
Did we actually find a current system where it broke with a straight
putenv("LC_ALL")?
cheers
andrew
On Wed, 2004-05-05 at 13:48, Bruce Momjian wrote: > I am seeing the following failure of initdb in CVS: > > FATAL: invalid value for parameter "client_encoding": "" I get the same thing.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I am seeing the following failure of initdb in CVS:
Okay, I did some more work on handling unsetenv cleanly ... give it
another try.
regards, tom lane
Thanks, works. --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I am seeing the following failure of initdb in CVS: > > Okay, I did some more work on handling unsetenv cleanly ... give it > another try. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Andrew Dunstan <andrew@dunslane.net> writes:
> Did we actually find a current system where it broke with a straight
> putenv("LC_ALL")?
Well, the Single Unix Spec does not say that that works, and neither
does the HPUX man page for putenv, so you're going to have a hard time
convincing me that it's a portable solution. I think the real story is
simply that no one has tested the C version of initdb hard enough to
notice whether that line actually accomplished anything or not.
regards, tom lane
Tom Lane said:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Did we actually find a current system where it broke with a straight
>> putenv("LC_ALL")?
>
> Well, the Single Unix Spec does not say that that works, and neither
> does the HPUX man page for putenv, so you're going to have a hard time
> convincing me that it's a portable solution.
Yeah, you're right. In fact SUS seems to be quite brain-dead on this - I
can't see that it says anything about how to unset an enviroment value.
How strange.
> I think the real story is
> simply that no one has tested the C version of initdb hard enough to
> notice whether that line actually accomplished anything or not.
>
I tested on the platforms that were available to me.
OTOH, I wonder if maybe what we previously did w.r.t. TZ didn't work, but
the timezone libs were smart enough to disregard an empty TZ value.
Anyway, you seem to have found a portable solution, so all's well that
ends well.
cheers
andrew
"Andrew Dunstan" <andrew@dunslane.net> writes:
> OTOH, I wonder if maybe what we previously did w.r.t. TZ didn't work, but
> the timezone libs were smart enough to disregard an empty TZ value.
The code in variable.c clearly does *not* work on machines where
putenv() copies what you hand it :-(. I suspect that no one noticed
because the clear_tz path isn't really used in normal situations.
I left it alone for the moment because I expect that we'll be ripping
it all out as soon as the dust settles with src/timezone. We can define
a less brain-dead API for testing validity of a timezone name ...
regards, tom lane