Re: separate serial_schedule useful?
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-10-07T13:19:14Z
Lists: pgsql-hackers
On Fri, Oct 6, 2017 at 4:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The other routine mistake, which I see Robert just made again, > is to break the at-most-twenty-parallel-tests-at-once convention. > I wonder if we can get in some sort of automated check for that. Argh. We can argue about whether that's my mistake or Ashutosh's mistake, but I do try to catch these things. It's just that there are so many rules that require a committer to (a) know the rule and (b) remember to enforce the rule that it's really easy to miss one. And I do know that rule, but it slipped my mind in the course of trying to make sure that we'd covered all the bases in terms of the feature itself. 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 feel like the need to manually enforce so many tedious coding rules is a real limiting factor on our ability to (a) involve new people in the project and (b) get their work committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL 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