Re: Move regression.diffs of pg_upgrade test suite
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2018-12-30T15:41:46Z
Lists: pgsql-hackers
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.dunstan@2ndquadrant.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
Commits
-
In the pg_upgrade test suite, don't write to src/test/regress.
- 5c0fee0be2f6 9.5.18 landed
- 5e89aa021e00 9.6.14 landed
- c44e9bc3a10f 10.9 landed
- 88a0e3daf862 11.4 landed
- 40b132c1afbb 12.0 landed
- e00b5f090fa0 9.5.18 landed
- 4f4b2d4161b1 9.6.14 landed
- 422584caf32f 10.9 landed
- d08d880ab41a 11.4 landed
- bd1592e85702 12.0 landed
-
In the pg_upgrade test suite, remove and recreate "tmp_check".
- f3798089d84e 9.5.18 landed
- 8e2b41ecf8ac 10.9 landed
- 63f82b384e67 9.6.14 landed
- 20103a26094b 11.4 landed
- 10b72deafea5 12.0 landed