On 1/20/18 5:47 PM, Michael Paquier wrote:
> On Fri, Jan 19, 2018 at 06:54:23PM -0300, Alvaro Herrera wrote:
>> Peter Eisentraut wrote:
>> If the only problem is that buildfarm would run tests twice, then I
>> think we should just press forward with this regardless of that: it
>> seems a chicken-and-egg problem, because buildfarm cannot be upgraded to
>> use some new test method if the method doesn't exist yet. As a
>> solution, let's just live with some run duplication for a period until
>> the machines are upgraded to a future buildfarm client code.
It also appears that the TAP tests don't have the infrastructure to be
able to run pg_ugrade properly, per below.
> The main complain I received about this move of the pg_upgrade tests to
> be a TAP one is that they don't support easily cross-major version
> upgrades, removing some abilities to what a developer or the builfarm
> can actually do.
Unless I read it wrong the buildfarm is not doing cross-version
upgrades, but a developer/user can do so manually using the same script?
> Making this possible would require first some
> refactoring of PostgresNode.pm so as a node is aware of the binary paths
> it uses to be able to manipulate multiple instances with different
> install paths at the same time.
Any idea of what the LOE would be for that?
Thanks,
--
-David
david@pgmasters.net