Re: Move regression.diffs of pg_upgrade test suite
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2018-12-30T16:28:56Z
Lists: pgsql-hackers
On Sun, Dec 30, 2018 at 10:41:46AM -0500, Andrew Dunstan wrote: > 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. > >> 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 > 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. There's no rush; I don't recall other reports of the spurious failure described in the original post. I'll plan to push the postgresql.git change around 2019-03-31, so animals updating within a month of release will have no degraded pg_upgradeCheck failure reports.
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