Re: Move regression.diffs of pg_upgrade test suite

On 12/26/18 5:44 PM, Noah Misch wrote:
> On Wed, Dec 26, 2018 at 05:02:37PM -0500, Tom Lane wrote:
>> Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
>>> On 12/23/18 10:44 PM, Noah Misch wrote:
>>>> A disadvantage of any change here is that it degrades buildfarm reports, which
>>>> recover slowly as owners upgrade to a fixed buildfarm release. This will be
>>>> similar to the introduction of --outputdir=output_iso. On non-upgraded
>>>> animals, pg_upgradeCheck failures will omit regression.diffs.
>>>>
>>>> I think the right fix, attached, is to use "pg_regress --outputdir" to
>>>> redirect these files to src/bin/pg_upgrade/tmp_check/regress.
>>> Seems reasonable.
>> Do we need to change anything in the buildfarm client to improve its
>> response to this? If so, seems like it might be advisable to make a
>> buildfarm release with the upgrade before committing the change.
>> Sure, not all owners will update right away, but if they don't even
>> have the option then we're not in a good place.
> It would have been convenient if, for each test target, PostgreSQL code
> decides the list of interesting log files and presents that list for the
> buildfarm client to consume. It's probably overkill to redesign that now,
> though. I also don't think it's of top importance to have unbroken access to
> this regression.diffs, because defects that cause this run to fail will
> eventually upset "install-check-C" and/or "check". Even so, it's fine to
> patch the buildfarm client in advance of the postgresql.git change:
>
> diff --git a/PGBuild/Modules/TestUpgrade.pm b/PGBuild/Modules/TestUpgrade.pm
> index 19b48b3..dfff17f 100644
> --- a/PGBuild/Modules/TestUpgrade.pm
> +++ b/PGBuild/Modules/TestUpgrade.pm
> @@ -117,11 +117,16 @@ sub check
> @checklog = run_log($cmd);
> }
>
> + # Pre-2019 runs could create src/test/regress/regression.diffs. Its
> + # inclusion is a harmless no-op for later runs; if another stage
> + # (e.g. make_check()) failed and created that file, the run ends before
> + # reaching this stage.
> my @logfiles = glob(
> "$self->{pgsql}/contrib/pg_upgrade/*.log
> $self->{pgsql}/contrib/pg_upgrade/log/*
> $self->{pgsql}/src/bin/pg_upgrade/*.log
> $self->{pgsql}/src/bin/pg_upgrade/log/*
> + $self->{pgsql}/src/bin/pg_upgrade/tmp_check/*/*.diffs
> $self->{pgsql}/src/test/regress/*.diffs"
> );
> foreach my $log (@logfiles)

I'll commit this or something similar, but I generally try not to make
new releases more frequently than once every 3 months, and it's only six
weeks since the last release. So unless there's a very good reason I am
not planning on a release before February.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services