From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Continuous buildfarm failures on hamster with bin-check |
Date: | 2017-04-18 14:57:15 |
Message-ID: | 11780.1492527435@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-04-18 15:00:23 | Re: Continuous buildfarm failures on hamster with bin-check |
Previous Message | Heikki Linnakangas | 2017-04-18 14:42:56 | Re: scram and \password |