Re: ECPG failure on BF member Vaquita (Windows Vista) - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: ECPG failure on BF member Vaquita (Windows Vista)
Date
Msg-id 462F6D99.5050602@dunslane.net
Whole thread Raw
In response to Re: ECPG failure on BF member Vaquita (Windows Vista)  (Dave Page <dpage@postgresql.org>)
Responses Re: ECPG failure on BF member Vaquita (Windows Vista)
List pgsql-hackers
Dave Page wrote:
> Michael Meskes wrote:
>   
>> On Wed, Apr 25, 2007 at 10:47:57AM +0100, Dave Page wrote:
>>     
>>> I'm seeing an ECPG-Check failure on Windows Vista - any ideas what might
>>> be causing this?
>>>       
>> Hmm, first glance suggests some permission problems. 
>>     
>
> Yes, that was my thought as well, however I ran cacls down the entire
> build tree, granting full control to Everyone on everything, but the
> problem persists.
>   

Please don't do that on your buildfarm repo copy (if that's what you 
did). You should not touch *anything* inside it. If need to you do this, 
make a copy (see later) and alter that.

If you did do this to the buildfarm repo copy, please blow it away so 
that buildfarm will get a fresh clean copy next time it runs.

> Additionally, all the other tests pass, including make check and make
> installcheck, so unless the ECPG tests are trying to create something
> outside of the buildtree, I don't think it is a permissions issue.
>
> Is there anything I can try building/running manually to help debug this?
>   


To recreate the failing buildfarm environment (including making an 
alterable repo copy), run the following (with suitable local mods):

run_build.pl --test --keepall

At the end of that you should have the build tree that was actually 
used, and the install tree too if it got that far. Then you can start 
playing manually.

Remember to move or remove the kept trees before your next buildfarm run.

cheers

andrew




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Kill a Long Running Query
Next
From: Heikki Linnakangas
Date:
Subject: Re: Avoiding unnecessary reads in recovery