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

From Noah Misch
Subject Re: Move regression.diffs of pg_upgrade test suite
Date
Msg-id 20181230162856.GA187973@gust.leadboat.com
Whole thread Raw
In response to Re: Move regression.diffs of pg_upgrade test suite  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: Move regression.diffs of pg_upgrade test suite
List 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.


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Unified logging system for command-line programs
Next
From: Tom Lane
Date:
Subject: Re: Removing --disable-strong-random from the code