Re: The xversion-upgrade test fails to stop server

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The xversion-upgrade test fails to stop server
Date: 2024-08-18 16:00:00
Message-ID: 5276b030-2b5a-968b-9e08-200ccd0b7772@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Andrew,

04.06.2024 14:56, Andrew Dunstan wrote:
>
>>
>> but I can't see ../snapshot_too_old/output_iso/regression.diff and
>> .../snapshot_too_old/output_iso/log/postmaster.log in the log.
>>
>>
>
> will do.
>

I've discovered a couple of other failures where the interesting log files
are not saved.

[1] has only inst/logfile saved and that's not enough for TAP tests in
src/test/modules.

I've emulated the failure (not trying to guess the real cause) with:
--- a/src/test/modules/test_custom_rmgrs/Makefile
+++ b/src/test/modules/test_custom_rmgrs/Makefile
@@ -14,0 +15,4 @@ TAP_TESTS = 1
+remove:
+    make uninstall
+install: remove

and saw mostly the same with the buildfarm client REL_17.

I've tried the following addition to run_build.pl:
@@ -2194,6 +2194,8 @@ sub make_testmodules_install_check
        my @logs = glob("$pgsql/src/test/modules/*/regression.diffs");
        push(@logs, "inst/logfile");
        $log->add_log($_) foreach (@logs);
+       @logs = glob("$pgsql/src/test/modules/*/tmp_check/log/*");
+       $log->add_log($_) foreach (@logs);
and it works as expected for me.

The output of another failure ([2]) contains only:
\342\226\266 1/1 + partition_prune                          3736 ms FAIL
but no regression.diffs
(Fortunately, in this particular case I found "FATAL:  incorrect checksum
in control file" in inst/logfile, so that can explain the failure.)

Probably, run_build.pl needs something like:
@@ -1848,7 +1848,7 @@ sub make_install_check
                @checklog = run_log("cd $pgsql/src/test/regress && $make $chktarget");
        }
        my $status = $? >> 8;
-       my @logfiles = ("$pgsql/src/test/regress/regression.diffs", "inst/logfile");
+       my @logfiles = ("$pgsql/src/test/regress/regression.diffs",
"$pgsql/testrun/regress-running/regress/regression.diffs", "inst/logfile");

>> A similar failure have occurred today:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=opaleye&amp;dt=2024-06-08%2001%3A41%3A41
>>
>> So maybe it would make sense to increase default PGCTLTIMEOUT for
>> buildfarm clients, say, to 180 seconds?
>
>
> Sure. For now I have added it to the config on crake, but we can make it a default.

By the way, opaleye failed once again (with 120 seconds timeout):
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=opaleye&dt=2024-08-13%2002%3A04%3A07

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gull&dt=2024-08-06%2014%3A56%3A39
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2024-08-17%2001%3A12%3A50

Best regards,
Alexander

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-08-18 17:13:36 Improving the notation for ecpg.addons rules
Previous Message walther 2024-08-18 14:30:11 Re: Meson far from ready on Windows