Re: meson: Make test output much more useful on failure (both in CI and locally)

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: meson: Make test output much more useful on failure (both in CI and locally)
Date: 2026-04-24 17:00:00
Message-ID: 3b239431-a945-4e2b-903d-22c7addc528e@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello hackers,

07.04.2026 16:15, Peter Eisentraut wrote:
> On 02.04.26 14:25, Andrew Dunstan wrote:
>> Committed with minor tidy up. The main change was to add a @CARP_NOT setting in Utils.pm, so that croak() would look
>> back past Cluster.pm to the TAP script caller.
>
> I would like to register a vote against this new behavior:

I've noticed another disadvantage of this log processing: [1] shows the
misc_functions test's failure, but we can't see timing of the test anymore:
# ok 27        + line                                     6713 ms
# ... 210 lines omitted ...
# ok 223       + reloptions                              18169 ms

Previously, a test report for the same failure contained:
ok 139       + merge                                   19699 ms
not ok 140   + misc_functions                          18003 ms
ok 141       + sysviews                                 7925 ms

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2026-04-24%2001%3A26%3A26

Best regards,10
Alexander

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-04-24 17:52:31 Re: Startup process deadlock: WaitForProcSignalBarriers vs aux process
Previous Message Richard Guo 2026-04-24 15:44:32 Re: Wrong results from inner-unique joins caused by collation mismatch