Hello,
Which distribution are you speaking about ?
I'm using Gentoo and postgresql is versioned : you install the versions you're looking for and switch form one to another using eselect
laurent@torchwood ~ $ eselect postgresql list
Available PostgreSQL Slots
11 11.7
12 * 12.2
Available PostgreSQL Slots
11 11.7
12 * 12.2
(I know my system is outdated : i'm blocked by regressions in PHP so don't updated this part for a while :) )
When you're upgrading your system, all supported version are rebuilt every time a dependencies change : should be long if you're running a large number of version but you keep a stable system.
Bye
Laurent
Le jeudi 25 novembre 2021, 17:41:35 UTC+1, Chocimier <chocimier@xxxxxxx> a écrit :
Hi,
How to provide Postgres for a binary rolling release Linux distribution?
Currently 9.6, 12 and 13 major versions are packaged in Void by me in
way described below.
No one reported practical problems with that, but some concerns arised,
mainly around shared libraries.
Constraints:
- Want to allow to migrate data to new version of server.
- Other software (postfix, qt5...) is linked dynamically to libpq.so,
and providing variants of those per postgres version is not desired.
- There are extensions provided (currently only postgis, more planned).
Current model is:
- Provide different major versions as packages installable at same
time, except from postgresql-libs (libpq, libpgtypes, libecpg.so).
Build every major version _N_ with different prefix: usr/lib/psqlN.
This allows usage of pg_upgrade to migrate data.
- Have one user-installable shared libraries package, always from
newest available version.
- Provide extensions for every version as different package built
against target postgres version (e.g. postgis-postgresql12).
- Do not rebuild packages depending on libpq.so when library is updated.
- Rebuild packages depending on libpq.so against newest version when
they are updated.
- Upgrade of postgresql-libs does not force people to install and use
newer server, this is done independently whenever they decide to.
Now, my questions:
- Is loading new major version library from old postgresql server,
client, extension valid?
- Is loading new major version library from package build against *old*
major version to talk to old server valid?
- Is loading new major version library from package build against *new*
major version to talk to old server valid?
- If any of above is wrong, what could be better model?
