From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: reducing isolation tests runtime |
Date: | 2019-02-13 17:03:39 |
Message-ID: | 20190213170339.7j5emqw6wvxiuuhv@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On 2019-02-13 10:58:50 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-02-13 17:41:41 | Re: reducing isolation tests runtime |
Previous Message | Andres Freund | 2019-02-13 17:01:13 | Re: pgsql: Change floating-point output format for improved performance. |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-02-13 17:05:18 | Re: Reaping Temp tables to avoid XID wraparound |
Previous Message | Tom Lane | 2019-02-13 16:57:32 | Re: subscriptionCheck failures on nightjar |