Re: pg_upgrade version checking questions

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Tomasz Szypowski <tomasz(dot)szypowski(at)gmail(dot)com>
Subject: Re: pg_upgrade version checking questions
Date: 2019-03-22 09:20:19
Message-ID: 57769959-8960-a9ca-fc9c-4dbb12629b8a@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-03-22 09:26:32 Re: [HACKERS] Can ICU be used for a database's default sort order?
Previous Message Michael Banck 2019-03-22 09:04:02 Re: Offline enabling/disabling of data checksums