Re: pg_upgrade version checking questions

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: pg_upgrade version checking questions
Дата
Msg-id CA+hUKGKv88aHOgNSdrsoJ1Zid5wTKu6So_xdAAi0csFW8YDb6w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade version checking questions  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
On Wed, Jul 31, 2019 at 3:13 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> > 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.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: benchmarking Flex practices
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Proposal to suppress errors thrown by to_reg*()