Re: reducing isolation tests runtime - Mailing list pgsql-hackers

From Andres Freund
Subject Re: reducing isolation tests runtime
Date
Msg-id 20190213170339.7j5emqw6wvxiuuhv@alap3.anarazel.de
Whole thread Raw
In response to Re: reducing isolation tests runtime  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: reducing isolation tests runtime
List pgsql-hackers
On 2019-02-13 10:58:50 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2019-Feb-13, Tom Lane wrote:
> >> Some of the slower buildfarm critters use MAX_CONNECTIONS to limit
> >> the load on their hosts.  As long as the isolation tests honor that,
> >> I don't see a real need for a separate serial schedule.
> 
> > MAX_CONNECTIONS was the only reason I didn't push this through.  Do you
> > (Andres) have any solution to that?
> 
> Doesn't the common pg_regress.c infrastructure handle that?
> We might need to improve isolation_main.c and/or the isolation
> Makefile to make it accessible.

> I suppose that in what I'm thinking about, MAX_CONNECTIONS would be
> interpreted as "max number of concurrent isolation scripts", which
> is not exactly number of connections.  A quick and dirty answer
> would be to have isolation_main.c divide the limit by a factor of 4
> or so.

I guess that could work, although it's certainly not too pretty.
Alternatively we could pre-parse the spec files, but that's a bit
annoying given isolationtester.c is a separate c file...

Do you have an idea why we have both max_concurrent_tests *and*
max_connections in pg_regress? ISTM the former isn't really useful given
the latter?

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: subscriptionCheck failures on nightjar
Next
From: Tom Lane
Date:
Subject: Re: Reaping Temp tables to avoid XID wraparound