Re: pg_upgrade version checking questions
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Cc: Tomasz Szypowski <tomasz.szypowski@gmail.com>
Date: 2019-03-19T15:16:12Z
Lists: 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
Commits
-
pg_upgrade: Check version of target cluster binaries
- f06b1c598254 14.0 landed
-
pg_upgrade: Default new bindir to pg_upgrade location
- 959f6d6a1821 13.0 landed
-
pg_upgrade: Check all used executables
- 0befb4f31386 13.0 landed