Re: transforms vs. CLOBBER_CACHE_ALWAYS - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: transforms vs. CLOBBER_CACHE_ALWAYS
Date
Msg-id 55437857.3040304@dunslane.net
Whole thread Raw
In response to Re: transforms vs. CLOBBER_CACHE_ALWAYS  (Christian Ullrich <chris@chrullrich.net>)
Responses Re: transforms vs. CLOBBER_CACHE_ALWAYS  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 04/30/2015 09:09 PM, Christian Ullrich wrote:
> * Andrew Dunstan:
>
>> friarbird is a FreeBSD buildfarm animal running with
>> -DCLOBBER_CACHE_ALWAYS. It usually completes a run in about 6.5 hours.
>> However, it's been stuck since Monday running the plpython regression
>> tests. The only relevant commit seems to be the transforms feature.
>> Here's what it's been doing:
>
>>     query            | SELECT cursor_plan();
>
> Same here, on jaguarundi. I actually killed it intentionally this 
> morning, hoping that whatever the problem was might have been fixed 
> already. No such luck.
>
> I would suspect that it might have something to do with the OS, if all 
> the other CCA animals weren't lining up nicely behind in the buildfarm 
> status page.
>
>> I imagine it was in some sort of infinite loop. gdb says it's all in
>> src/backend/utils/cache/plancache.c, although not the same line each
>> time I run it.
>
> I ktrace'd it this morning, but cleverly did not keep the dump. It 
> looked much the same to me, though, it was reading the same filenode 
> over and over again.
>


Yeah, this happened again this morning, so it seems to be quite reliably 
reproducible. I killed it and I've set friarbird to build without python 
for now, but this is clearly an issue that needs to be resolved.

Side thought - maybe we need some sort of timeout mechanism for the 
buildfarm to try to stop it from hanging. There is actually some timeout 
code in there from back in the CVS days when occasionally CVS would 
hang. It could be adapted to timeout other steps.

cheers

andrew



pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: initdb -S and tablespaces
Next
From: Robert Haas
Date:
Subject: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)