Postgres Pro
Downloads
Home   >   mailing lists

Thread: Isolation checks under MSVC

Isolation checks under MSVC

From
Andrew Dunstan
Date:
I've committed a bunch of changes both in the Postgres code and the 
buildfarm code to enable running the isolation checks under MSVC. 
There's one hurdle that I haven't overcome: the code tries to call 
"./isolationtester" and Windows barfs on it. I think we need to remove 
that way of doing things, and instead user a full path for such commands 
like we do elsewhere.

For now I have disabled the test on the one MSVC member I had enabled it 
for, to clear the buildfarm error. I had hoped to get this completed 
before I leave for pgcon in the morning, but now it will have to wait a 
week before I am able to test it again, as I won't have a suitable 
machine with me in Ottawa.

cheers

andrew

Re: Isolation checks under MSVC

From
Magnus Hagander
Date:
On Mon, May 16, 2011 at 06:14, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> I've committed a bunch of changes both in the Postgres code and the
> buildfarm code to enable running the isolation checks under MSVC. There's
> one hurdle that I haven't overcome: the code tries to call
> "./isolationtester" and Windows barfs on it. I think we need to remove that
> way of doing things, and instead user a full path for such commands like we
> do elsewhere.

That seems like the reasonable way to fix it, yes.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: Isolation checks under MSVC

From
Andrew Dunstan
Date:

On 05/16/2011 04:09 AM, Magnus Hagander wrote:
> On Mon, May 16, 2011 at 06:14, Andrew Dunstan<andrew@dunslane.net>  wrote:
>> I've committed a bunch of changes both in the Postgres code and the
>> buildfarm code to enable running the isolation checks under MSVC. There's
>> one hurdle that I haven't overcome: the code tries to call
>> "./isolationtester" and Windows barfs on it. I think we need to remove that
>> way of doing things, and instead user a full path for such commands like we
>> do elsewhere.
> That seems like the reasonable way to fix it, yes.

It turns out that the real problem was that I'd put a spurious 
underscore in the name of the .exe in the MSVC build. That's been fixed 
now and this is all working.

cheers

andrew