Le jeudi 25 novembre 2021, 17:41:35 UTC+1, Chocimier <chocimier@tlen.pl> 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?