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>
Cc: pgsql-hackers@lists.postgresql.org,
Tomasz Szypowski <tomasz.szypowski@gmail.com>
Date: 2019-03-22T09:20:19Z
Lists: pgsql-hackers
On 2019-03-19 16:51, Tom Lane wrote: > 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. The RPM packages do that, but the Debian packages do not. >>> 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? I'm still in favor of defaulting --new-bindir appropriately. It seems silly not to. We know where the directory is, we don't have to ask anyone. -- 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