Thread: 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?
On 11/25/21 10:43 AM, Chocimier wrote:
The Debian PostgreSQL Maintainers has a separate tree for each major version. They do not rename the binaries.
$ dir /usr/lib/postgresql/
total 8
drwxr-xr-x 4 root root 4096 2020-11-18 09:22:00 12/
drwxr-xr-x 4 root root 4096 2019-05-24 13:46:12 9.6/
postgres@haggis:~$ dir /usr/lib/postgresql/12
total 16
drwxr-xr-x 2 root root 4096 2021-09-08 00:43:11 bin/
drwxr-xr-x 4 root root 12288 2021-09-08 00:43:11 lib/
$ dir /usr/lib/postgresql/9.6
total 16
drwxr-xr-x 2 root root 4096 2021-09-08 00:43:13 bin/
drwxr-xr-x 3 root root 12288 2021-09-08 00:43:13 lib/
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.
The Debian PostgreSQL Maintainers has a separate tree for each major version. They do not rename the binaries.
$ dir /usr/lib/postgresql/
total 8
drwxr-xr-x 4 root root 4096 2020-11-18 09:22:00 12/
drwxr-xr-x 4 root root 4096 2019-05-24 13:46:12 9.6/
postgres@haggis:~$ dir /usr/lib/postgresql/12
total 16
drwxr-xr-x 2 root root 4096 2021-09-08 00:43:11 bin/
drwxr-xr-x 4 root root 12288 2021-09-08 00:43:11 lib/
$ dir /usr/lib/postgresql/9.6
total 16
drwxr-xr-x 2 root root 4096 2021-09-08 00:43:13 bin/
drwxr-xr-x 3 root root 12288 2021-09-08 00:43:13 lib/
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?
--
Angular momentum makes the world go 'round.
Angular momentum makes the world go 'round.
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@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?
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