Re: Move regression.diffs of pg_upgrade test suite

On Sun, Dec 30, 2018 at 11:28:56AM -0500, Noah Misch wrote:
> 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.

The buildfarm release landed 2019-04-04, so I pushed $SUBJECT today, in commit
bd1592e.  The buildfarm was unanimous against it, for two reasons.  First, the
patch was incompatible with NO_TEMP_INSTALL=1, which the buildfarm uses.  In a
normal "make -C src/bin/pg_upgrade check", the act of creating the temporary
installation also creates "tmp_check".  With NO_TEMP_INSTALL=1, it's instead
the initdb that creates "tmp_check".  I plan to fix that by removing and
creating "tmp_check" early.  This fixes another longstanding bug; a rerun of
"vcregress upgradecheck" would fail with 'directory "[...]/tmp_check/data"
exists but is not empty'.  It's also more consistent with $(prove_check),
eliminates the possibility that a file in "tmp_check" survives from an earlier
run, and ends NO_TEMP_INSTALL=1 changing the "tmp_check" creation umask.

Second, I broke "vcregress installcheck" by writing "funcname $arg" where
funcname was declared later in the file.  Neither the function invocation
style nor the function declaration order were in line with that file's style,
so I'm changing both.