Skip site navigation (1) Skip section navigation (2)

Re: Fix for pg_upgrade's forcing pg_controldata into English

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix for pg_upgrade's forcing pg_controldata into English
Date: 2010-09-02 00:08:47
Message-ID: 4298.1283386127@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> I certainly hope that pg_regress isn't freeing the strings it passes
>> to putenv() ...

> pg_regress does not restore these settings (it says with C/English) so
> the code is different.

That's not what I'm on about.  You're trashing strings that are part of
the live environment.  It might accidentally fail to fail for you, if
your version of free() doesn't immediately clobber the released storage,
but it's still broken.  Read the putenv() man page.

+ #ifndef WIN32
+ 		char	   *envstr = (char *) pg_malloc(ctx, strlen(var) +
+ 							strlen(val) + 1);
+ 
+ 		sprintf(envstr, "%s=%s", var, val);
+ 		putenv(envstr);
+ 		pg_free(envstr);
                ^^^^^^^^^^^^^^^^
+ #else
+ 		SetEnvironmentVariableA(var, val);
+ #endif

The fact that there is no such free() in pg_regress is not an oversight
or shortcut.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-09-02 00:12:27
Subject: Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression
Previous:From: Bruce MomjianDate: 2010-09-01 23:56:45
Subject: Re: Fix for pg_upgrade's forcing pg_controldata into English

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group