Re: pg_upgrade version checking questions
От | Daniel Gustafsson |
---|---|
Тема | Re: pg_upgrade version checking questions |
Дата | |
Msg-id | A378B36C-A948-43E3-9714-6605979F6CB6@yesql.se обсуждение исходный текст |
Ответ на | Re: pg_upgrade version checking questions (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: pg_upgrade version checking questions
Re: pg_upgrade version checking questions |
Список | pgsql-hackers |
> On 27 Jul 2019, at 08:42, Peter Eisentraut <peter.eisentraut@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. cheers ./daniel
В списке pgsql-hackers по дате отправления: