Re: longfin and tamandua aren't too happy but I'm not sure why

From: Andres Freund <andres(at)anarazel(dot)de>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: longfin and tamandua aren't too happy but I'm not sure why
Date: 2022-10-01 22:15:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2022-10-01 11:14:20 -0500, Justin Pryzby wrote:
> I just tried this, which works fine at least for v11-v14:
> | git checkout origin/REL_15_STABLE .cirrus.yml src/tools/ci
> v15a
> v15b
> v13
> v12
> v11

Cool, thanks for trying that! I wonder if there's any problems on other

> (I still suggest my patches to run all tests using vcregress. The number of
> people who remember that, for v15, cirrusci runs incomplete tests is probably
> fewer than five.)

Andrew, the defacto maintainer of src/tools/msvc, kind of NACKed those. But
the reasoning might not hold with vcregress being on life support.

OTOH, to me the basic advantage is to have *any* CI coverage. We don't need to
put the bar for the backbranches higher than were we were at ~2 weeks ago.

> If cirrusci were backpatched, it'd be kind of nice to use a ccache key
> that includes the branch name (but maybe the overhead of compilation is
> unimportant compared to the workload induced by cfbot).

Hm. The branch name in general sounds like it might be too broad, particularly
for cfbot. I think we possibly should just put the major version into
.cirrus.yml and use that as the cache key. I think that'd also solve some of
the "diff against what" arguments we've had around your CI improvements.

> A gripe from me: the regression.diffs and other logs from the SQL regression
> tests are in a directory called "main" (same for "isolation"). I imagine I
> won't be the last person to spend minutes looking through the list of test dirs
> for the entry called "regress", conclude that it's inexplicably absent, and
> locate it only after reading src/test/regress/

I'd have no problem renaming main/isolation to isolation/isolation and
main/regress to pg_regress/regress or such.

FWIW, if you add --print-errorlogs meson test will show you the output of just
failed tests, which for pg_regress style tests will include the path to

The differences that caused some tests to fail can be viewed in the
file "/srv/dev/build/m/testrun/cube/regress/regression.diffs". A copy of the test summary that you see
above is saved in the file "/srv/dev/build/m/testrun/cube/regress/regression.out".

It's too bad the default of --print-errorlogs can't be changed.

Unfortunately we don't print something as useful in the case of tap tests. I
wonder if we should do something like

diff --git i/src/test/perl/PostgreSQL/Test/ w/src/test/perl/PostgreSQL/Test/
index 99d33451064..acc18ca7c85 100644
--- i/src/test/perl/PostgreSQL/Test/
+++ w/src/test/perl/PostgreSQL/Test/
@@ -239,6 +239,8 @@ END
# Preserve temporary directories after (1) and after (2).
$File::Temp::KEEP_ALL = 1 unless $? == 0 && all_tests_passing();
+ diag("test logfile: $test_logfile");


Potentially doing so only if $? != 0.

This would make the output for a failing test end like this:
―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
# Failed test at /home/andres/src/postgresql/contrib/amcheck/t/ line 20.
# Failed test at /home/andres/src/postgresql/contrib/amcheck/t/ line 22.
# test logfile: /srv/dev/build/m/testrun/amcheck/001_verify_heapam/log/regress_log_001_verify_heapam
# Looks like you failed 2 tests of 275.

(test program exited with status code 2)

which should make it a lot easier to find the log?


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-10-01 22:57:22 Re: Question: test "aggregates" failed in 32-bit machine
Previous Message Jonathan S. Katz 2022-10-01 20:58:28 Re: Question: test "aggregates" failed in 32-bit machine