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.

-- 
  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, Pennsylvania 19073

Wed, 5 May 2004 13:48:59 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
initdb failure in CVS
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.


Wed, 05 May 2004 15:15:29 -0400
Rod Taylor <pg@rbt.ca>
Re: initdb failure in CVS
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

Wed, 05 May 2004 15:53:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: initdb failure in CVS 
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





Wed, 05 May 2004 16:09:52 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: initdb failure in CVS
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

Wed, 05 May 2004 17:20:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: initdb failure in CVS 

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, Pennsylvania 19073

Wed, 5 May 2004 18:22:47 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: initdb failure in CVS
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

Wed, 05 May 2004 21:17:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: initdb failure in CVS 
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



Thu, 6 May 2004 09:35:21 -0400 (EDT)
"Andrew Dunstan" <andrew@dunslane.net>
Re: initdb failure in CVS
"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

Thu, 06 May 2004 10:28:56 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: initdb failure in CVS 