On Fri, Nov 4, 2016 at 4:16 AM, Kuntal Ghosh <kuntalghosh.2...@gmail.com> wrote: > On Thu, Nov 3, 2016 at 8:24 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Nov 2, 2016 at 10:30 AM, Kuntal Ghosh >> <kuntalghosh.2...@gmail.com> wrote: >>> - Another suggestion was to remove wal_consistency from PostgresNode.pm >>> because small buildfarm machines may suffer on it. Although I've no >>> experience in this matter, I would like to be certain that nothings breaks >>> in recovery tests after some modifications. >> >> I think running the whole test suite with this enabled is going to >> provoke complaints from buildfarm owners. That's too bad, because I >> agree with you that it would be nice to have the test coverage, but it >> seems that many of the buildfarm machines are VMs with very minimal >> resource allocations -- or very old physical machines -- or running >> with settings like CLOBBER_CACHE_ALWAYS that make runs very slow. If >> you blow on them too hard, they fall over.
Count me in. My RPIs won't like that! Actually I have a couple of things internally mimicking the buildfarm client code on machines with far higher capacity. And FWIW I am definitely going to enable this option in the test suite, finishing with reports here. > Thanks Robert. I got your point. Then, as Michael has suggested, it is nice to > have some environment variable to pass optional conf parameters during > tap-tests. > Implementing this feature actually solves the problem. We just need make PostgresNode.pm aware of something like PGTAPOPTIONS to enforce a server started by TAP tests to append options to it. There is already PGCTLTIMEOUT that behaves similarly. Even if this brings extra load to buildfarm owners, that will limit complaints. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
