Peter Eisentraut <peter.eisentr...@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
