[oi-dev] Moving on with postgresql

[Jim Klimov]

On April 17, 2021 10:16:16 PM UTC, Andreas Wacknitz <A.Wacknitz at gmx.de> wrote:
>Am 17.04.21 um 23:46 schrieb Gary Mills:
>> OI currently has postgresql versions: 95 96 10 11 12 .  The OI
>> default, in shared-macros.mk, is 95 .  However, the postgresql
>> developers report that 95 is unsupported, but 13 is available and
>> supported.  Something has to change in OI to move forward with
>> postgresql.
>>
>> Here are some actions that could be taken with OI.  We could change
>> the default version to 10.  I, myself, would prefer 11.  We could
>> obsolete 95.  I'd prefer obsoleting 95 and 96.  We could add version
>> 13, but only after 96 is obsoleted.  We should limit the number of
>> postgresql versions in OI, after all.  Finally, we could make no
>> obsoletions or additions, retaining even the unsupported 95.  Which
>> would you prefer?
>>
>> I have not investigated two questions.  Perhaps you can tell me? 
>What
>> are the consequences of obsoleting 95?  What are the consequences of
>> the default change?
>>
>>
>You are right, removing PostgreSQL-9.5 is overdue.
>And yes, we should think about reducing the number of PostgreSQL
>versions we support because of our limited man power.
>Furthermore, we (at least I) don't know who is really using PostgreSQL
>and what version is being used.
>
>Changing the settings to a newer version and removing 9.5 (and whatever
>else) is only the first step.
>The 2nd step is to republish all depending packages with the new
>default
>version. What versions can be obsoleted and removed
>depend on this step: we might need to update/patch or remove dependant
>packages if they don't build with the newer default version anymore.
>To find out which packages depend on postgresql isn't hard, but it
>might
>be a lot more work to find out what needs to be done to update all of
>them.
>Both steps need to be prepared and then executed right after each other
>(but serially).
>
>
>_______________________________________________
>oi-dev mailing list
>oi-dev at openindiana.org
>https://openindiana.org/mailman/listinfo/oi-dev

Just a couple of cents to consider: IIRC major database engine upgrades more than once caused me to wish to know in advance that an OS update would deprecate an older version and while it is still available in the running BE I should export the data just before rebooting, so I can reimport it from scratch in the new BE. I think I had to reboot back to make an export in hindsight, for both mysql and postgres updates over the years.

In many cases it is not just a drop-in change of software - new versions bring and remove storage engines, and what not, refusing to just use old data files. On systems with larger databases an upgrade may suddenly need unplanned disk space overhead.

Granted, many upgrades similarly require to rework configuration files, but often that is not so "expensive", nor disruptive (does not require a reboot back to old BE).

So, dropping unsupported code is reasonable, but warn people in all-caps if the upgrade is likely not just a `pkg image-update; beadm activate ...; init 6`. And maybe refer to that for a next year's snapshot release notes too :)

Jim

--
Typos courtesy of K-9 Mail on my Android