|From:||Andrew Dunstan <andrew(at)dunslane(dot)net>|
|To:||Christian Ullrich <chris(at)chrullrich(dot)net>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: transforms vs. CLOBBER_CACHE_ALWAYS|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|Next Message||Robert Haas||2015-05-01 13:00:01||Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)|
|Previous Message||Abhijit Menon-Sen||2015-05-01 12:42:53||Re: initdb -S and tablespaces|