Re: TAP output format in pg_regress - Mailing list pgsql-hackers

> On 26 Nov 2022, at 20:37, Nikolay Shaplov <dhyan@nataraj.su> wrote:
> В письме от пятница, 25 ноября 2022 г. 00:20:01 MSK пользователь Daniel
> Gustafsson написал:

> "Thius" seems to be a typo :-)

Correct, fixed in the attached.

> + #define bail_noatexit(...) bail_out(true, __VA_ARGS__)
>
> BTW what does "noat" stands for? I thought it is typo too :-) and originally
> meant to be "not".

Calling _exit() will cause exit handler functions registered with atexit() to
not be invoked, no noatexit was intentional spelling.

> Just out of overaccuracy: Logic here have not changed. Can we keep ifs, elses
> and may be indent offsets of lines that did not change as they were to have
> nicer diff? Would make understanding this changeset more easy... Or this is
> work of pg_indent that spoils it?

The diff algorithm decided that this was the compact way of displaying the
unified diff, probably because too many lines in proximity changed.  While
avoiding moving the comments to before the line might mitigate that somewhat I
prefer this greatly to a slightly easier to read diff.

> While looking at the my output I am getting wrong offset for
> sanity_check:
>
> ok 84 hash_func 121 ms
> ok 85 errors 68 ms
> ok 86 infinite_recurse 233 ms
> ok 87 sanity_check 144 ms
> # parallel group (20 tests): select_into delete random select_having
> select_distinct_on namespace select_implicit case prepared_xacts subselect
> transactions portals select_distinct union arrays update hash_index join
> aggregates btree_index
> ok 88 select_into 134 ms
> ok 89 select_distinct 812 ms
>
> (also for select_parallel write_parallel vacuum_parallel and fast_default)
>
> I guess the intention was to align them too...

No, they are aligned in such a way because they are running outside of a
parallel group.  Note that it's not part of the "parallel group" note
preceeding the tests:

# parallel group (6 tests):  collate.linux.utf8 amutils psql_crosstab psql rules stats_ext
ok 146              rules                              507 ms
ok 147              psql                               448 ms
ok 148              psql_crosstab                       47 ms
ok 149              amutils                             39 ms
ok 150              stats_ext                         2578 ms
ok 151              collate.linux.utf8                  27 ms
ok 152       select_parallel                           668 ms
ok 153       write_parallel                             84 ms
ok 154       vacuum_parallel                            90 ms

In the previous format it's a bit clearer, and maybe we should adopt that for
TAP as well?

parallel group (6 tests):  collate.linux.utf8 amutils psql_crosstab psql rules stats_ext
     rules                        ... ok          488 ms
     psql                         ... ok          430 ms
     psql_crosstab                ... ok           47 ms
     amutils                      ... ok           38 ms
     stats_ext                    ... ok         2301 ms
     collate.linux.utf8           ... ok           24 ms
test select_parallel              ... ok          641 ms
test write_parallel               ... ok           83 ms
test vacuum_parallel              ... ok           87 ms

That would if so make the output something like the below.  Personally I think
the "test" prefix adds little value since everything printed are test suites,
and we are already today using indentation for grouping parallel tests.

# parallel group (6 tests):  collate.linux.utf8 amutils psql_crosstab psql rules stats_ext
ok 146              rules                              507 ms
ok 147              psql                               448 ms
ok 148              psql_crosstab                       47 ms
ok 149              amutils                             39 ms
ok 150              stats_ext                         2578 ms
ok 151              collate.linux.utf8                  27 ms
ok 152       test select_parallel                      668 ms
ok 153       test write_parallel                        84 ms
ok 154       test vacuum_parallel                       90 ms

--
Daniel Gustafsson        https://vmware.com/