From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Reducing the runtime of the core regression tests |
Date: | 2019-04-10 22:54:25 |
Message-ID: | 14131.1554936865@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-04-10 18:35:15 -0400, Tom Lane wrote:
>> ... What I did instead was to shove
>> that test case and some related ones into a new plpgsql test file,
>> src/pl/plpgsql/src/sql/plpgsql_trap.sql, so that it's not part of the
>> core regression tests at all. (We've talked before about moving
>> chunks of plpgsql.sql into the plpgsql module, so this is sort of a
>> down payment on that.) Now, if you think about the time to do
>> check-world rather than just the core regression tests, this isn't
>> obviously a win, and in fact it might be a loss because the plpgsql
>> tests run serially not in parallel with anything else.
> Hm, can't we "just" parallelize the plpgsql schedule instead?
If somebody wants to work on that, I won't stand in the way, but
it seems like material for a different patch.
>> Thoughts? Anyone object to making these sorts of changes
>> post-feature-freeze?
> Hm. There's some advantage to doing so, because it won't break any large
> pending changes. But it's also possible that it'll destabilize the
> buildfarm some. In personal capacity I'm like +0.5.
My thought was that there is (hopefully) going to be a lot of testing
going on over the next few months, so making that faster would be
a useful activity.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-04-10 22:54:44 | Re: serializable transaction: exclude constraint violation (backed by GIST index) instead of ssi conflict |
Previous Message | Andres Freund | 2019-04-10 22:48:30 | Re: Reducing the runtime of the core regression tests |