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

From Andrew Dunstan
Subject Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check
Date
Msg-id 5bdba3de-986d-a413-cc6c-2cb4372bf2b5@2ndQuadrant.com
Whole thread Raw
In response to Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers

On 04/18/2017 08:59 AM, Michael Paquier wrote:
>> 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.



How is that going to deal with your wal_*_timeout etc settings?

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




pgsql-hackers by date:

Previous
From: Maksim Milyutin
Date:
Subject: Re: [HACKERS] [PATCH] New command to monitor progression of longrunning queries
Next
From: Keith Fiske
Date:
Subject: Re: [HACKERS] Passing values to a dynamic background worker