On Tue, 4 May 2021 11:32:40 +0200 Markus Demleitner
<msdem...@ari.uni-heidelberg.de> wrote:
Ah. That might be a solution. One thing that needs to be
ensured, though, is that on upgrades, the old pgsphere packages do
not get removed until the operator asks dpkg to explicitly. Perhaps
stating the obvious, here's what needs to happen when upgrading from,
say pg 11 to 13:
(1) normal dist-upgrade pulls in (hopefully) postgres-13, keeps
postgres-11 running as normal (hence, pgsphere-11 must still be
there).
(2) operator runs pg_upgrade (for which both pg-13 and pg-11 must be
present with all necessary extensions)
(3) the last step of pg_upgrade is to make pg-13 the default db server,
and pg-11 isn't started any more
(4) the operator can now purge postgres-11 together with the
version 11 extensions.
Thanks for making this clear ;-)
Unfortunately, this is not the case currently because we have
Package: postgresql-13-pgsphere
Source: pgsphere
Version: 1.1.1+2020-10-20-1
Replaces: postgresql-pgsphere (<< 1.1.1+2020)
Provides: postgresql-pgsphere
Depends: libc6 (>= 2.29), libgcc-s1 (>= 3.0), libhealpix-cxx2 (>=
3.60.0), libstdc++6 (>= 5.2), postgresql-13
Conflicts: postgresql-pgsphere (<< 1.1.1+2020)
Package: postgresql-13-q3c
Source: postgresql-q3c
Version: 2.0.0-4
Replaces: postgresql-q3c (<< 2.0.0-2)
Provides: postgresql-q3c
Depends: postgresql-13, libc6 (>= 2.29)
Conflicts: postgresql-q3c (<< 2.0.0-2)
which causes the pg-11 extensions to be removed before pg_upgrade can be
performed. But I think these Conflicts+Replaces can be safely dropped
since all files in these two packages are in versioned paths.
I'll file two RC bugs ...
My hunch is that when pgsphere-11 is installed as an auto-dependency
of pgsphere, it will be dropped in step (1), at which point pg-11
probably won't even start any more, or at least will be unable to
dump for the pg_upgrade.
It will only be dropped automatically if you enable autoremoval of
unneeded packages during the upgrade. But then postgresql-11 will
probably go away as well...
Andreas
