Re: Move regression.diffs of pg_upgrade test suite

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Move regression.diffs of pg_upgrade test suite
Дата
Msg-id 37ead3b7-b4a9-5a1f-6a10-c6ab9eb0d2aa@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: Move regression.diffs of pg_upgrade test suite  (Noah Misch <noah@leadboat.com>)
Ответы Re: Move regression.diffs of pg_upgrade test suite  (Noah Misch <noah@leadboat.com>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Augment every test postgresql.conf
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Unified logging system for command-line programs