On Tue, Apr 18, 2017 at 9:35 PM, Andrew Dunstan <andrew.duns...@2ndquadrant.com> wrote: > > > On 04/18/2017 08:23 AM, Michael Paquier wrote: >> On Tue, Apr 18, 2017 at 9:13 PM, Andrew Dunstan >> <andrew.duns...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers