Horton

Thread

Commits

  1. Enforce our convention about max number of parallel regression tests.

  2. Clean up sloppy maintenance of regression test schedule files.

  1. separate serial_schedule useful?

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2017-10-06T19:37:09Z

    I noticed that the test "hash_func" was listed in parallel_schedule but
not in serial_schedule.  I have seen that a few times recently where a
patch proposes to add a new test file but forgets to add it to the
serial_schedule.

I wonder whether it's still useful to keep two separate test lists.  I
think we could just replace make installcheck with what make
installcheck-parallel MAX_CONNECTIONS=1 does.  Thoughts?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  2. Re: separate serial_schedule useful?

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-10-06T20:16:06Z

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> I noticed that the test "hash_func" was listed in parallel_schedule but
> not in serial_schedule.  I have seen that a few times recently where a
> patch proposes to add a new test file but forgets to add it to the
> serial_schedule.

Yeah, this is way too routine :-(

> I wonder whether it's still useful to keep two separate test lists.  I
> think we could just replace make installcheck with what make
> installcheck-parallel MAX_CONNECTIONS=1 does.  Thoughts?

Hm, that seems like potentially a good idea.  I can't see an argument
against it offhand.

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.

			regards, tom lane

  3. Re: separate serial_schedule useful?

    Robert Haas <robertmhaas@gmail.com> — 2017-10-07T13:19:14Z

    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

  4. Re: separate serial_schedule useful?

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-10-07T14:23:08Z

    Robert Haas <robertmhaas@gmail.com> writes:
> 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.

> 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.

			regards, tom lane

  5. Re: separate serial_schedule useful?

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-10-07T16:49:08Z

    I wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.)

			regards, tom lane

  6. Re: separate serial_schedule useful?

    Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> — 2017-10-09T10:42:19Z

    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