Re: The xversion-upgrade test fails to stop server - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: The xversion-upgrade test fails to stop server
Date
Msg-id 2e1b35eb-96c3-43cf-bebf-1ab952704a85@dunslane.net
Whole thread Raw
In response to Re: The xversion-upgrade test fails to stop server  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-hackers
On 2024-08-18 Su 12:00 PM, Alexander Lakhin wrote:
> 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");


Thanks, I have added these tweaks.



>
>>> A similar failure have occurred today:
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=opaleye&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
>


Yeah. In the next release the default will increase to 180.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Ajay Pal
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Next
From: Bertrand Drouvot
Date:
Subject: Re: define PG_REPLSLOT_DIR