Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check |
Дата | |
Msg-id | 20170418150023.7u46ill2ieqoao2r@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check
|
Список | pgsql-hackers |
Tom Lane wrote: > Michael Paquier <michael.paquier@gmail.com> writes: > > That's the point I am trying to make upthread: slow buildfarm animals > > should have minimal impact on core code modifications. We could for > > example have one environment variable that lists all the parameters to > > modify in a single string and appends them at the end of > > postgresql.conf. But honestly I don't think that this is necessary if > > there is only one variable able to define a base directory for > > temporary statistics as the real bottleneck comes from there at least > > in the case of hamster. > > FWIW, I'm a bit suspicious of relocating the temp stats directory as > being a reliable fix for this. It looks to me like hamster isn't that > much slower than gaur/pademelon, ie the same machine that was my primary > development machine for well over a decade, and on which I have NEVER > seen a "stats collector not responding" failure. Plus, if hamster's > main storage is SSD, that seems unlikely to be slower than the spinning > rust in gaur/pademelon. So I can't escape the suspicion that something > else is going on there. Seemingly-unexplainable stats collector problems > have been a bugaboo for a long time ... It's an SD card (the kind typically used in cameras and phones), not SSD. Saying it's slow is an understatement. It's *excruciatingly* slow. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: