Обсуждение: As a Linux distro, how to package multiple postgres major versions?

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?

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?

Hello,

I left process as described in previous message.

That's after people on irc confirmed that using libpq across versions is fine,
and realizing that libpq is just a client to talk to server, and doesn't
implement other server functionality.

W dniu 25.11.2021 o 21:17, Laurent FAILLIE pisze:
> Hello,
> 
> Which distribution are you speaking about ?

> When you're upgrading your system, all supported version are rebuilt every time a dependencies change

Void Linux, a binary distribution. Packages are rebuild here only on shlib changes, not after every dependency update,
intrust to library developers keeping compatibility otherwise, so far with good outcome.
 
Switching versions is not yet enabled for postgres, but planned on next update.

Thanks for tips!

On 1/4/22 13:15, Chocimier wrote:
> Hello,
> 
> I left process as described in previous message.
> 
> That's after people on irc confirmed that using libpq across versions is 
> fine,
> and realizing that libpq is just a client to talk to server, and doesn't
> implement other server functionality.

As long as you are using the latest version of libpq. For a recent 
thread on where it may be causing an issue because of incompatibilities:

https://www.postgresql.org/message-id/4042326.1641321158%40sss.pgh.pa.us
> 
> W dniu 25.11.2021 o 21:17, Laurent FAILLIE pisze:
>> Hello,
>>
>> Which distribution are you speaking about ?
> 
>> When you're upgrading your system, all supported version are rebuilt 
>> every time a dependencies change
> 
> Void Linux, a binary distribution. Packages are rebuild here only on 
> shlib changes, not after every dependency update, in trust to library 
> developers keeping compatibility otherwise, so far with good outcome.
> Switching versions is not yet enabled for postgres, but planned on next 
> update.
> 
> Thanks for tips!
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com