Skip site navigation (1) Skip section navigation (2)

Re: Need a builtin way to run all tests faster manner

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>,Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Need a builtin way to run all tests faster manner
Date: 2017-03-11 19:48:31
Message-ID: 20170311194831.vm5ikpczq52c2drg@alap3.anarazel.de (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
On 2017-03-11 12:05:23 -0500, Tom Lane wrote:
> I wrote:
> > I believe the core problem is that contrib/test_decoding's regresscheck
> > and isolationcheck targets each want to use ./tmp_check as their
> > --temp-instance.  make has no reason to believe it shouldn't run those
> > two sub-jobs in parallel, but when it does, we get two postmasters trying
> > to share the same directory.  This looks reasonably straightforward to
> > solve, but I'm not entirely familiar with the code here, and am not
> > sure what is the least ugly way to fix it.
> 
> Enlarging on that: if I cd into contrib/test_decoding and do
> "make check -j4" or so, it reliably fails.

Yep, can reproduce here as well. Interesting that, with -j16, I could
survive several dozen runs from the toplevel locally.


> This is a localized patch that only fixes things for
> contrib/test_decoding; what I'm wondering is if it would be better to
> establish a more widespread convention that
> $(pg_isolation_regress_check) should use a different --temp-instance
> directory than $(pg_regress_check) does.

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)?

- Andres


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2017-03-11 20:02:12
Subject: Re: Explicit subtransactions for PL/Tcl
Previous:From: Pavel StehuleDate: 2017-03-11 19:44:31
Subject: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group