Re: Windows buildfarm failures
От | Andrew Dunstan |
---|---|
Тема | Re: Windows buildfarm failures |
Дата | |
Msg-id | 45B0E7BA.6020108@dunslane.net обсуждение исходный текст |
Ответ на | Re: Windows buildfarm failures (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: