On Wed, Jul 31, 2019 at 3:13 AM Daniel Gustafsson <dan...@yesql.se> wrote: > > On 27 Jul 2019, at 08:42, Peter Eisentraut > > <peter.eisentr...@2ndquadrant.com> wrote: > > I have committed 0002, 0003, and 0004. > > Thanks! > > > The implementation in 0001 (Only allow upgrades by the same exact > > version new bindir) has a problem. It compares (new_cluster.bin_version > > != PG_VERSION_NUM), but new_cluster.bin_version is actually just the > > version of pg_ctl, so this is just comparing the version of pg_upgrade > > with the version of pg_ctl, which is not wrong, but doesn't really > > achieve the full goal of having all binaries match. > > Right, it seemed the cleanest option at the time more or less based on the > issues outlined below. > > > I think a better structure would be to add a version check for each > > validate_exec() so that each program is checked against pg_upgrade. > > This should mirror what find_other_exec() in src/common/exec.c does. In > > a better world we would use find_other_exec() directly, but then we > > can't support -B. Maybe expand find_other_exec() to support this, or > > make a private copy for pg_upgrade to support this. (Also, we have two > > copies of validate_exec() around. Maybe this could all be unified.) > > I’ll take a stab at tidying all of this up to require less duplication, we’ll > see where that ends up.
Hi Daniel, I've moved this to the next CF, because it sounds like you're working on a new version of 0001. If I misunderstood and you're happy with just 0002-0004 being committed for now, please feel free to mark the September entry 'Committed'. -- Thomas Munro https://enterprisedb.com
