Re: Continuous buildfarm failures on hamster with bin-check

Tom Lane wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)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