Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check
От | Andrew Dunstan |
---|---|
Тема | Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check |
Дата | |
Msg-id | 5bdba3de-986d-a413-cc6c-2cb4372bf2b5@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check (Michael Paquier <michael.paquier@gmail.com>) |
Список | 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 по дате отправления: