Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check |
Дата | |
Msg-id | 20170418071506.fpcuumjyxeal55a2@alap3.anarazel.de обсуждение исходный текст |
Ответ на | [HACKERS] Continuous buildfarm failures on hamster with bin-check (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check
|
Список | pgsql-hackers |
Hi, On 2017-04-18 16:07:38 +0900, Michael Paquier wrote: > Some of you may have noticed that hamster is heavily red on the > buildfarm. I have done a bit of investigation, and I am able to > reproduce the failure manually. But actually after looking at the logs > the error has obviously showed up: > 2017-04-16 05:07:19.650 JST [18282] LOG: database system is ready to > accept connections > 2017-04-16 05:08:36.725 JST [18296] LOG: using stale statistics > instead of current ones because stats collector is not responding > 2017-04-16 05:10:22.207 JST [18303] t/010_pg_basebackup.pl LOG: > terminating walsender process due to replication timeout > 2017-04-16 05:10:30.180 JST [18306] LOG: using stale statistics > instead of current ones because stats collector is not responding > > Stale regressions means that the system is just constrained so much > that things are timing out. > > In order to avoid such failures with normal regression tests, I have > set up extra_config so as stats_temp_directory goes to a tmpfs to > avoid stale statistics How high do you need to make the hardcoded limit for this to succeed without a tmpfs? If hamster fails this regularly I think we have to do something about it, rather than paper over it. What's the storage situation currently like? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: