Re: Move regression.diffs of pg_upgrade test suite

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Move regression.diffs of pg_upgrade test suite
Date: 2018-12-24 20:11:33
Message-ID: ede9f7a3-2082-ce59-abb0-fe867dc03bbb@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mitar 2018-12-24 20:59:43 Feature: triggers on materialized views
Previous Message Andrew Dunstan 2018-12-24 19:46:48 Re: pg_dumpall --exclude-database option