Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check
Date
Msg-id 11780.1492527435@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
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 ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] scram and \password
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check