Re: Windows buildfarm failures - Mailing list pgsql-hackers

From Stefan Kaltenbrunner
Subject Re: Windows buildfarm failures
Date
Msg-id 45B0E2DD.9030804@kaltenbrunner.cc
Whole thread Raw
In response to Windows buildfarm failures  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Windows buildfarm failures
Re: Windows buildfarm failures
List pgsql-hackers
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Stefan Kaltenbrunner wrote:
> 
>>> yeah - looks like it's the autovacuum change - snake is now passing the
>>> numeric-test but still fails the stats one ...
>> Interesting -- both yak and snake are failing in a very similar way.
>> I'll investigate it tomorrow if no one beats me to it.
> 
> All our Windows buildfarm machines are failing.  AFAICT, the first
> failure was on Yak, 
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=yak&dt=2007-01-16%2021:55:20
> 
> and the last successful run just before that seems to come from Snake,
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snake&dt=2007-01-16%2014:30:00
> 
> The only changes that went in in that period are the patch that enabled
> autovacuum by default, an information_schema fix and a TODO file change.
> The only that could cause this problem seems to be the autovacuum enable
> bit.

I think this one:

http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bear&dt=2007-01-19%2006:06:02

is fallout from the autovacuum changes too - it seems that initdb is
picking a low value (20) for max_connections on that box and autovacuum
is acting as an additional client that will cause the maximum of allowed
connections to exceed during the parallel tests and therefor resulting
in the failure.


Stefan


pgsql-hackers by date:

Previous
From: Darcy Buskermolen
Date:
Subject: Re: [GENERAL] Autovacuum Improvements
Next
From: Andrew Dunstan
Date:
Subject: Re: Windows buildfarm failures