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 <mich...@paquier.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 >
