From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: mingw check hung |
Date: | 2009-01-29 13:06:44 |
Message-ID: | 4981A9E4.9050806@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander wrote:
>> Specifically, it's the SetEnvironmentVariable() call from
>> pgwin32_putenv() called from pgwin32_unsetenv(). When this is disabled
>> things work just fine.
>>
>
> That's strange :( What arguments are it sent to the function? Since this
> is an API function, it really shouldn't behave differently between mingw
> and msvc, so it must be something that goes wrong with the arguments.
>
> Also, Tom mentioned earlier that we may be including *two* replacements
> for unsetenv(), which could be what's causing the problem. Can you check
> if that is happening and try to disable the one in port/unsetenv.c and
> see if that changes things?
>
>
>
I've already ruled out that hypothesis by forcing the call direct to
pgwin32_unsetenv() instead of relying on the macro, in initdb.c.
There are only two such calls in initdb.c: the arguments are "LC_ALL"
and "PGCLIENTENCODING".
I wonder if this version of SetEnvironmentVariable is sufficiently dumb
that it fails badly if given a NULL second argument for a value that is
not in fact in the environment (as I would normally expect of these on
Windows)?
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2009-01-29 13:15:01 | Re: pg_upgrade project status |
Previous Message | Simon Riggs | 2009-01-29 12:54:42 | Re: Hot standby, recovery infra |