On 02/27/2016 09:25 AM, Robert Haas wrote:
On Sat, Feb 27, 2016 at 7:08 PM, Andrew Dunstan <and...@dunslane.net> wrote:What I had in mind was something like the attached. In testing this seems to do the right thing, and the nice part is that it will be picked up by the buildfarm in the one case that's relevant, namely the ecpg tests. The only fly in the ointment is that there are a few places that set --temp-config explicitly: ./contrib/test_decoding/Makefile: --temp-config $(top_srcdir)/contrib/test_decoding/logical.conf \ ./contrib/test_decoding/Makefile: --temp-config $(top_srcdir)/contrib/test_decoding/logical.conf \ ./src/test/modules/commit_ts/Makefile:REGRESS_OPTS = --temp-config=$(top_srcdir)/src/test/modules/commit_ts/commit_ts.conf ./src/test/modules/test_rls_hooks/Makefile:REGRESS_OPTS = --temp-config=$(top_srcdir)/src/test/modules/test_rls_hooks/rls_hooks.conf Perhaps what we need to do is modify pg_regress.c slightly to allow more than one --temp-config argument. But that could be done later.Well, I'm pretty interested in using --temp-config for parallelism testing; I want to be able to run the whole regression test suite with a given --temp-config. I'm in agreement with this change but if it doesn't play well with that need, I suppose I'll be writing that pg_regress.c patch sooner rather than later.
"doesn't meet your need" is probably a better way of putting it. The facility's use has grown beyond what I originally envisaged, so I think we will need that patch.
Would you like me to apply what I have? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
