Re: mingw check hung

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

In response to

Responses

Browse pgsql-hackers by date

  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