Re: [HACKERS] Need a builtin way to run all tests faster manner - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Need a builtin way to run all tests faster manner
Date
Msg-id 20170313025833.c3iy4zlhwe2vpvtc@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Need a builtin way to run all tests faster manner  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Need a builtin way to run all tests faster manner  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
0;115;0c
On 2017-03-11 22:14:07 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2017-03-11 11:48:31 -0800, Andres Freund wrote:
> >> I think that'd be a good plan.  We probably should also keep --outputdir
> >> seperate (which test_decoding/Makefile does, but
> >> pg_isolation_regress_check doesn't)?
> 
> > Here's a patch doing that (based on yours).  I'd be kind of inclined to
> > set --outputdir for !isolation tests too; possibly even move tmp_check
> > below output_iso/ output_regress/ or such - but that seems like it
> > potentially could cause some disagreement...
> 
> This looks generally sane to me, although I'm not very happy about folding
> the "$(MKDIR_P) output_iso" call into pg_isolation_regress_check --- that
> seems weird and unlike the way it's done for the regular regression test
> case.

Yea, not super happy about that either - alternatively we could fold it
into pg_regress.  But given the way that prove_checks works, I thought
it'd not be too ugly comparatively.

- Andres



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Logical replication existing data copy
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] scram and \password