Re: Continuous buildfarm failures on hamster with bin-check

On Tue, Apr 18, 2017 at 9:35 PM, Andrew Dunstan
<andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
>
>
> On 04/18/2017 08:23 AM, Michael Paquier wrote:
>> On Tue, Apr 18, 2017 at 9:13 PM, Andrew Dunstan
>> <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
>>> Yeah, but the way you have done it could also to lead to errors unless
>>> you're very careful, as I found on axolotl (which died recently,
>>> unfortunately). There I had to set the stats_temp directory to a
>>> branch-specific name so a crash on branch A didn't leave stats picked up
>>> by a run on branch B. I had a script that ran before every buildfarm run
>>> that made sure the branch-specific directories existed on the tmpfs.
>> I didn't consider that. Still hamster is only set to run master so
>> that's not a problem. Running more branches would be too much for this
>> little dear as it includes TAP tests.
>>
>>>> but it is not possible to set up that with the
>>>> TAP tests. I could always disable --enable-tap-tests on this machine
>>>> but I don't think that this is a correct answer. Something that could
>>>> be done is to use an environment variable to set up a base directory
>>>> for all the nodes created in PostgresNode.pm, and use that for
>>>> temporary statistics with a custom folder name. But that's not
>>>> scalable if we want to enforce more parameter.
>>> What more parameters do you want?
>> Increasing wal_sender_timeout and wal_receiver_timeout can help in
>> reducing the failures seen.
>
> OK, but you're only talking about a handful of these, right?

Yup, that would be one solution but that's not attacking the problem
at its root.

> Lets's say we have a bunch of possible environment settings with names
> that all begin with "PG_TAP_" PostgresNode.pm could check for the
> existence of these and take action accordingly, and you could set them
> on a buildfarm animal in the config file, or for interactive use in your
> .profile.

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. When initializing a node via PostgresNode.pm,
we would just check for this variable, and the init() routine just
creates a temporary folder in it, setting up temp_stats_path in
postgresql.conf.
--
Michael