Michael Paquier <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers