Re: Move regression.diffs of pg_upgrade test suite

From: Noah Misch <noah(at)leadboat(dot)com>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Move regression.diffs of pg_upgrade test suite
Date: 2018-12-30 16:28:56
Message-ID: 20181230162856.GA187973@gust.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(dot)dunstan(at)2ndquadrant(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-30 16:47:03 Re: Removing --disable-strong-random from the code
Previous Message Peter Eisentraut 2018-12-30 16:07:37 Unified logging system for command-line programs