Re: separate serial_schedule useful?
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
From: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-10-09T10:42:19Z
Lists: pgsql-hackers
On Sat, Oct 7, 2017 at 10:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >> Robert Haas <robertmhaas@gmail.com> writes: Sorry, my bad. I wasn't aware of this rule. I should have looked at the beginning of the file for any rules. >>> There's no reason why pg_regress couldn't have a >>> --bail-if-group-size-exceeds=N argument, or why we couldn't have a >>> separate Perl script to validate the schedule file as part of the >>> build process. > >> I'd go for the former approach; seems like less new code and fewer cycles >> used to enforce the rule. > > Concretely, how about the attached? (Obviously we'd have to fix > parallel_schedule before committing this.) > Thanks, this will help. May be we should set default to 20 instead of unlimited. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
Commits
-
Enforce our convention about max number of parallel regression tests.
- ef73a8162a5f 11.0 landed
-
Clean up sloppy maintenance of regression test schedule files.
- 1fdab4d5aa47 11.0 landed