Re: pg_regress: schedule multi-line test groups

Hi All,

I just received an email about this requiring a rebase.

Is there any chance this will be committed, or should I abandon it?

Regards,
Alexandre

On Sun, Sep 20, 2026 at 6:56 PM Alexandre Felipe <
o(dot)alexandre(dot)felipe(at)gmail(dot)com> wrote:

> v2 failed on CFBot with error: 'INFINITY' undeclared.
> v2.1 does the same as v2 but without using INFINITY.
>
> On Sun, Sep 20, 2026 at 8:50 AM Alexandre Felipe
> <o(dot)alexandre(dot)felipe(at)gmail(dot)com> wrote:
> >
> >
> > Thank you for your looking into it Daniel
> >
> > On Fri, Sep 18, 2026 at 10:31 AM Daniel Gustafsson <daniel(at)yesql(dot)se>
> wrote:
> >>
> >> > On 17 Sep 2026, at 10:43, Alexandre Felipe <
> o(dot)alexandre(dot)felipe(at)gmail(dot)com> wrote:
> >>
> >> > Actually, I think we should support arbitrary size test groups and
> run them on a pool
> >> > from a queue that would possibly make the regression faster as today
> we always
> >> > wait for the slowest test in each group.
> >>
> >> I know of ongoing, as of yet unpublished, work in this area to improve
> this
> >> scheduling which will also change the syntax. There is a bit
> complexity to it
> >> than just picking from a pool since there are inter-suite dependencies.
> >
> >
> > An easy gain would be to somehow transpose execution, currently we put
> together
> > things to indicate that they are independent, it would be more readable
> if we used
> > the lines to indicate dependency.
> >
> > The right way to handle dependency is by writing a dependency tree and
> doing
> > a topological sort, like makefiles, but to keep the syntax backward
> compatible
> > we could do something like this
> >
> > # tests that have to run in isolation
> > test: setup_test
> > test: sanity_check
> > # tests that have to respect certain order
> > test sequentially: create_am psql
> > # where a test should wait for multiple tests that can run in parallel
> > test sequentially: (geometry create_index_spgist hash_index brin) amutils
> > # tests that can mix with other tests
> > test concurrently: compression compression_lz4 compression_pglz cluster
> >
> > But please, let's first get the multiline syntax over the fence.
> >
> > v2 is logging the effective concurrency of the groups during the
> execution
> > (we can't optimise what we don't measure).
> > e.g:
> > # effective concurrency 5.80 / 18
> > # effective concurrency 3.83 / 15
> >
> >
> > + /*
> >>
> >> + * Found `test: # no tests` treat it as a
> multiline test group
> >> + */
> >> if (num_tests == 0)
> >> {
> >> - bail("syntax error in schedule file
> \"%s\" line %d: %s",
> >> - schedule, line_num, scbuf);
> >> + multiline_test = true;
> >> + }
> >>
> >> This will allow empty test groups which we currently treat as an
> error. This
> >> schedule:
> >
> >
> > Fixed, also improved the error messages
> >
> > Also, if we are to change the accepted syntax, why limit to single line
> or
> >>
> >> multiline, why not accept any whitespace separated name between ^test:
> and
> >> (^test|EOF)? Something like the below:
> >>
> >> test: boolean
> >> char
> >> name
> >
> >
> > Minimalism. in v2 I am trying to do something more like what you
> described
> >
> > The schedule syntax in v2 should be
> >
> > * Schedule = (Blank | Comment | Group)*
> > * Group = "test:" (Line | Comment) (Indent Line)*
> > * Line = token (Space+ token)* Comment?
> > * Blank = '\n'
> > * Comment = '#' [^\n]* \n
> > * Indent = [\t ]+
> >
> > But I won't be surprised if you find inconsistencies between that and
> what
> > was actually implemented at this stage.
> >
> >
> > Regards,
> >
>