Re: Move regression.diffs of pg_upgrade test suite - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Move regression.diffs of pg_upgrade test suite
Date
Msg-id ede9f7a3-2082-ce59-abb0-fe867dc03bbb@2ndQuadrant.com
Whole thread Raw
In response to Move regression.diffs of pg_upgrade test suite  (Noah Misch <noah@leadboat.com>)
Responses Re: Move regression.diffs of pg_upgrade test suite
List pgsql-hackers
On 12/23/18 10:44 PM, Noah Misch wrote:
> src/bin/pg_upgrade/test.sh runs installcheck, which writes to files in
> src/test/regress.  This has at least two disadvantages when check-world runs
> both this test suite and the "make check" suite:
>
> 1. The suite finishing second will overwrite the other's regression.{out,diffs}.
> 2. If these suites run a given test file in parallel (possible with "make -j
>    check-world"), they simultaneously edit a file in src/test/regress/results.
>    This can cause reporting of spurious failures.  On my system, the symptom
>    is a regression.diffs indicating that the .out file contained ranges of NUL
>    bytes (holes) and/or lacked expected lines.
>
> 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.  I chose that
> particular path because it will still fit naturally if we ever rewrite test.sh
> using src/test/perl.  I'm recommending that the buildfarm capture[1] files
> matching src/bin/pg_upgrade/tmp_check/*/*.diffs, which will work even if we
> make this test suite run installcheck more than once.  This revealed a few
> places where tests assume @abs_builddir@ is getcwd(), which I fixed.
>
> Thanks,
> nm
>
> [1] https://github.com/PGBuildFarm/client-code/blob/REL_9/PGBuild/Modules/TestUpgrade.pm#L126

Seems reasonable.

cheers

andrew


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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_dumpall --exclude-database option
Next
From: Mitar
Date:
Subject: Feature: triggers on materialized views