Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two
Date
Msg-id 20180322013957.GD2490@paquier.xyz
Whole thread Raw
In response to Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two  (David Steele <david@pgmasters.net>)
Responses Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Wed, Mar 21, 2018 at 10:51:04AM -0400, David Steele wrote:
> On 3/6/18 4:12 PM, Tom Lane wrote:
> It seems the consensus is that we'll need a build farm update before we
> can move forward with the patch and that we don't need to wait long for
> people to upgrade.
>
> Andrew, do you have a date for the next release?

Even if a lighter version of this patch stripped from multi-version
support (Who uses that actually?) knowing that the buildfarm code has
its own set of modules to do the same may be a good step forward as per
the feedback of this thread people would like to unify the existing
scripts.

We could also try to figure later on how to merge the buildfarm code
into upstream and if it actually makes sense or not, which is something
I am not completely convinced is worth it.  This would remove the need
of any complicated refactoring in PostgresNode.pm to handle binary paths
for a single node, at the cost of of course removing cross-upgrade
checks from the tree.

Still I definitely agree that a release of the buildfarm client should
happen first.  9 days before the end of the commit, the window may be at
the end too short for v11.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PoC PATCH] Parallel dump to /dev/null
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] taking stdbool.h into use