From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
cc: pgsql-hackers@lists.postgresql.org,
        Tomasz Szypowski <tomasz.szypowski@gmail.com>
Subject: Re: pg_upgrade version checking questions
In-reply-to: <b659c1df-c37a-52da-da7f-e0659c34c92a@2ndquadrant.com>
References: <9328.1552952117@sss.pgh.pa.us>
 <b659c1df-c37a-52da-da7f-e0659c34c92a@2ndquadrant.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
	message dated "Tue, 19 Mar 2019 16:16:12 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13425.1553010710.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 Mar 2019 11:51:50 -0400
Message-ID: <13426.1553010710@sss.pgh.pa.us>
Precedence: bulk

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_dum=
p
>> 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%40va=
nquo.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