Re: [HACKERS] separate serial_schedule useful? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] separate serial_schedule useful?
Date
Msg-id CA+TgmobswsS7TQSTNWHO87x5GhTQXqniWa+hD5XS6RGdc4rxiw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] separate serial_schedule useful?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] separate serial_schedule useful?
List 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: amul sul
Date:
Subject: Re: [HACKERS] [POC] hash partitioning
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Discussion on missing optimizations