> On 26 Nov 2022, at 20:37, Nikolay Shaplov <dh...@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/
v13-0001-Change-pg_regress-output-format-to-be-TAP-compli.patch
Description: Binary data
