[prev in list] [next in list] [prev in thread] [next in thread]
List: postgresql-general
Subject: Re: As a Linux distro, how to package multiple postgres major versions?
From: Laurent FAILLIE <l_faillie () yahoo ! com>
Date: 2021-11-25 20:17:38
Message-ID: 1884327497.2485548.1637871458632 () mail ! yahoo ! com
[Download RAW message or body]
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
(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?
[Attachment #3 (text/html)]
<html><head></head><body><div class="yahoo-style-wrap" style="font-family:Helvetica \
Neue, Helvetica, Arial, \
sans-serif;font-size:13px;"><div>Hello,</div><div><br></div><div dir="ltr" \
data-setdir="false">Which distribution are you speaking about ?</div><div dir="ltr" \
data-setdir="false"><br></div><div dir="ltr" data-setdir="false">I'm using Gentoo and \
postgresql is versioned : you install the versions you're looking for and switch form \
one to another using eselect</div><div dir="ltr" data-setdir="false"><br></div><div \
dir="ltr" data-setdir="false"><div>laurent@torchwood ~ $ eselect postgresql \
list<br>Available PostgreSQL Slots<br> \
11 \
11.7<br> 12 * \
12.2<br><br></div><div dir="ltr" data-setdir="false">(I know my system is outdated : \
i'm blocked by regressions in PHP so don't updated this part for a while :) \
)</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" \
data-setdir="false">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.</div><div dir="ltr" \
data-setdir="false"><br><div>Bye</div><div><br></div><div dir="ltr" \
data-setdir="false">Laurent<br></div></div></div><div id="yahoo_quoted_8301286086" \
class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, \
sans-serif;font-size:13px;color:#26282a;">
<div>
Le jeudi 25 novembre 2021, 17:41:35 UTC+1, Chocimier \
<chocimier@tlen.pl> a écrit : </div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">Hi,<br></div><div dir="ltr"><br></div><div \
dir="ltr">How to provide Postgres for a binary rolling release Linux \
distribution?<br></div><div dir="ltr">Currently 9.6, 12 and 13 major versions are \
packaged in Void by me in<br></div><div dir="ltr">way described below.<br></div><div \
dir="ltr">No one reported practical problems with that, but some concerns \
arised,<br></div><div dir="ltr">mainly around shared libraries.<br></div><div \
dir="ltr"><br></div><div dir="ltr">Constraints:<br></div><div dir="ltr">- Want to \
allow to migrate data to new version of server.<br></div><div dir="ltr">- Other \
software (postfix, qt5...) is linked dynamically to libpq.so,<br></div><div \
dir="ltr">and providing variants of those per postgres version is not \
desired.<br></div><div dir="ltr">- There are extensions provided (currently only \
postgis, more planned).<br></div><div dir="ltr"><br></div><div dir="ltr">Current \
model is:<br></div><div dir="ltr">- Provide different major versions as packages \
installable at same<br></div><div dir="ltr">time, except from postgresql-libs (libpq, \
libpgtypes, libecpg.so).<br></div><div dir="ltr">Build every major version _N_ with \
different prefix: usr/lib/psqlN.<br></div><div dir="ltr">This allows usage of \
pg_upgrade to migrate data.<br></div><div dir="ltr">- Have one user-installable \
shared libraries package, always from<br></div><div dir="ltr">newest available \
version.<br></div><div dir="ltr">- Provide extensions for every version as different \
package built<br></div><div dir="ltr">against target postgres version (e.g. \
postgis-postgresql12).<br></div><div dir="ltr">- Do not rebuild packages depending on \
libpq.so when library is updated.<br></div><div dir="ltr">- Rebuild packages \
depending on libpq.so against newest version when<br></div><div dir="ltr">they are \
updated.<br></div><div dir="ltr">- Upgrade of postgresql-libs does not force people \
to install and use<br></div><div dir="ltr">newer server, this is done independently \
whenever they decide to.<br></div><div dir="ltr"><br></div><div dir="ltr">Now, my \
questions:<br></div><div dir="ltr">- Is loading new major version library from old \
postgresql server,<br></div><div dir="ltr">client, extension valid?<br></div><div \
dir="ltr">- Is loading new major version library from package build against \
*old*<br></div><div dir="ltr">major version to talk to old server \
valid?<br></div><div dir="ltr">- Is loading new major version library from package \
build against *new*<br></div><div dir="ltr">major version to talk to old server \
valid?<br></div><div dir="ltr">- If any of above is wrong, what could be better \
model?<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div></div> </div>
</div></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic