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
Date: Tue, 19 Mar 2019 11:51:50 -0400
Message-ID: <13426.1553010710@sss.pgh.pa.us> (raw)
In-Reply-To: <b659c1df-c37a-52da-da7f-e0659c34c92a@2ndquadrant.com>
References: <9328.1552952117@sss.pgh.pa.us>
<b659c1df-c37a-52da-da7f-e0659c34c92a@2ndquadrant.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@2ndquadrant.com, tomasz.szypowski@gmail.com
Subject: Re: pg_upgrade version checking questions
In-Reply-To: <13426.1553010710@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox