Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> 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.
I'm not really getting your point here. Packagers ordinarily tie
those versions together anyway, I'd expect --- there's no upside
to not doing so, and plenty of risk if one doesn't, because of
exactly the sort of coordinated-changes hazard I'm talking about here.
>> 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)
Mmm. The point that a default is of no particular use to scripts is
still valid. Shall we then remove the useless call to find_my_exec?
regards, tom lane