Re: pg_upgrade version checking questions

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: pg_upgrade version checking questions
Дата
Msg-id b659c1df-c37a-52da-da7f-e0659c34c92a@2ndquadrant.com
обсуждение исходный текст
Ответ на pg_upgrade version checking questions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_upgrade version checking questions
Список pgsql-hackers
On 2019-03-19 00:35, Tom Lane wrote:
> 2. check_cluster_versions() insists that the target version be the
> same major version as pg_upgrade itself, but is that really good enough?
> As things stand, it looks like pg_upgrade 11.3 would happily use pg_dump
> 11.1, or vice versa.

I'd hesitate to tie this down too much.  It's possible that either the
client or the server package cannot currently be upgraded because of
some other dependencies.  In fact, a careful packager might as a result
of a change like this tie the client and server packages together with
an exact version match.  This has the potential to make the global
dependency hell worse.

> 3. Actually, I'm kind of wondering why pg_upgrade has a --new-bindir
> option at all, rather than just insisting on finding the new-version
> executables in the same directory it is in.  This seems like, at best,
> a hangover from before it got into core.  Even if you don't want to
> remove the option, we could surely provide a useful default setting
> based on find_my_exec.

Previously discussed here:
https://www.postgresql.org/message-id/flat/1304710184.28821.9.camel%40vanquo.pezone.net
 (Summary: right)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: [HACKERS] Cached plans and statement generalization
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Online verification of checksums