Re: pg_regress: schedule multi-line test groups

From: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_regress: schedule multi-line test groups
Date: 2026-09-20 17:56:55
Message-ID: CAE8JnxOCb+O1k-+=2vnMLPLo-ZrsyC--+iKZWLFopOh9DQQLAw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v2.1-0001-pg_regress-multi-line-test-groups.patch application/octet-stream 16.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kiran Kaki 2026-09-20 18:40:18 Re: pg_walinspect: fix LSN validation messages and empty range handling
Previous Message Ziming Zhang 2026-09-20 16:16:42 Re: [PATCH] Combine qual-based and NOT NULL proofs when reducing outer joins