On 4/24/23 23:05, Tomas Vondra wrote:
>
>
> On 4/24/23 17:46, Tom Lane wrote:
>> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>>> On 2023-Apr-23, Tomas Vondra wrote:
>>>> Both cases have a patch extending pageinspect to show the new flag, but
>>>> obviously we should commit that only in master. In backbranches it's
>>>> meant only to make testing easier.
>>
>>> In backbranches, I think it should be reasonably easy to add a
>>> --1.7--1.7.1.sql file and set the default version to 1.7.1; that then
>>> enables us to have the functionality (and the tests) in older branches
>>> too. If you just add a --1.X.1--1.12.sql version to each branch that's
>>> identical to that branch's current pageinspect version upgrade script,
>>> that would let us have working upgrade paths for all branches. This is
>>> a bit laborious but straightforward enough.
>>
>> "A bit laborious"? That seems enormously out of proportion to the
>> benefit of putting this test case into back branches. It will have
>> costs for end users too, not only us. As an example, it would
>> unecessarily block some upgrade paths, if the upgraded-to installation
>> is slightly older and lacks the necessary --1.X.1--1.12 script.
>>
>
> Why would that block the upgrade? Presumably we'd add two upgrade
> scripts in the master, to allow upgrade both from 1.X and 1.X.1.
>
D'oh! I just realized I misunderstood the issue. Yes, if the target
version is missing the new script, that won't work. I'm not sure how
likely that is - in my experience people refresh versions at the same
time - but it's certainly an assumption we shouldn't do, I guess.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
