Stefan Kaltenbrunner wrote:
> 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.
>
>
>
>
If so, that's a case of driver error, I think. The buildfarm member
should set MAX_CONNECTIONS => '10' or similar in the build_env stanza of
the config file.
cheers
andrew