Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

Hello Michael,

This patch needs the update from 201a76183 -- the function `get_new_node`
no longer exists.

Running check tests in the pg_upgrade folder fails for this reason.

Thank you,
Rachel

On Tue, Sep 7, 2021 at 2:06 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Tue, May 18, 2021 at 10:49:39AM +0900, Michael Paquier wrote:
> > Makes sense. For now, I'll update this patch set so as it is possible
> > to use custom dumps, as an option in parallel of pg_regress when
> > specifying a different source code path. I'll also decouple the
> > business with probin updates and stick with the approach used by the
> > buildfarm code.
>
> This has proved to not be that difficult. With the updated version
> attached, pg_upgrade has two modes to set up the old instance used for
> the upgrade with older binaries:
> - With oldsrc and oldinstall set, pg_regress gets used, same way as
> HEAD.
> - With olddump and oldinstall set, an old dump is loaded instead in
> the old instance before launching the upgrade.
>
> oldsrc and olddump are exclusive options. Similarly to HEAD, the
> dumps taken from the old and new instances generate diffs that can be
> inspected manually. The updates of probin are done without any
> dependencies to the source path of the old instance, copying from the
> buildfarm.
>
> While on it, I have fixed a couple of things that exist in test.sh but
> were not reflected in this new script:
> - Handling of postfix operations with ~13 clusters.
> - Handling oldstyle_length for ~9.6 clusters.
> - Handling of EXTRA_REGRESS_OPT.
>
> This stuff still needs to be expanded depending on how PostgresNode is
> made backward-compatible, but I'll wait for that to happen before
> going further down here. I have also spent some time testing all that
> with MSVC, and the installation paths used for pg_regress&co make the
> script a tad more confusing, so I have dropped this part for now.
>
> Thanks,
> --
> Michael
>