Your message dated Tue, 8 Jun 2021 10:31:36 +0200 with message-id <dd66512c-d504-48e8-5e77-8ba815294...@xs4all.nl> and subject line Re: Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis has caused the Debian Bug report #988722, regarding postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 988722: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988722 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: postgresql-common Architecture: amd64 Version: 225 Severity: serious Justification: Potential data loss (lower at your discretion) Tags: bullseye X-Debbugs-CC: d.fil...@web.de During an upgrade from Buster to Bullseye I also had to upgrade a cluster from postgresql 11 to 13. The cluster had the postgis extension enabled (postgis 2.5.1) and one table with columns of types from postgis. My typescript tells me that during "apt full-upgrade" postgresql-11-postgis-2.5 was removed. After "apt full-upgrade" was done I installed postgresql-13-postgis-3-scripts thinking that it would be necessary for migrating any postgis metadata tables. Then I tried to migrate the cluster by running "pg_upgradecluster 11 main", but the migration failed (the error message roughly was "$lib/postgis-2.5 not found" or sth. like that; I didn't log that part). I reactivated the Buster repos in /etc/apt/sources.list and downgraded some packages back so that I could install postgresql-11-postgis-2.5-scripts again. I did not install postgresql-11-postgis-2.5, though (which, as far as I can tell, would have been impossible anyway due to conflicting dependencies, which was presumably also the reason for why it was automatically removed). Resolving the dependency rat's nest was not easy. Here's the state after: # aptitude versions '?or(~npostgis, ~npostgres) ~i' \ |sed 's@i[ ][ ]@i M @;s@ \([0-9]\+\)$@ locally \1@' \ |paste - - -|column -t Package libreoffice-sdbc-postgresql: i A 1:7.0.4-3 testing 500 Package postgis: i M 3.1.1+dfsg-1 testing 500 Package postgis-gui: i M 2.5.1+dfsg-1 locally 100 Package postgresql: i M 13+225 testing 500 Package postgresql-11: i M 11.12-0+deb10u1 locally 100 Package postgresql-11-postgis-2.5-scripts: i M 2.5.1+dfsg-1 locally 100 Package postgresql-11-python3-multicorn: i M 1.3.4-4 locally 100 Package postgresql-13: i A 13.2-1 testing 500 Package postgresql-13-postgis-3: i M 3.1.1+dfsg-1 testing 500 Package postgresql-13-postgis-3-scripts: i A 3.1.1+dfsg-1 testing 500 Package postgresql-client-11: i M 11.12-0+deb10u1 locally 100 Package postgresql-client-13: i A 13.2-1 testing 500 Package postgresql-client-common: i A 225 testing 500 Package postgresql-common: i A 225 testing 500 Package postgresql-contrib: i M 13+225 testing 500 Package postgresql-doc: i M 13+225 testing 500 Package postgresql-doc-11: i M 11.12-0+deb10u1 locally 100 Package postgresql-doc-13: i A 13.2-1 testing 500 Packages listed as "locally" are Buster packages. After that I reran "pg_upgradecluster 11 main" and this time the upgrade worked (but with error messages, which I foolishly did not log). However, after temporarily reenabling the old 11 cluster to check if anything was missing I noticed that the table with postgis columns was not copied over, and the postgis extension does not show up in the upgraded cluster either when running: psql -c '\dx' (it does in the 11 cluster). I'm filing this bug also to learn how this was supposed to work. Does the automatic removal of postgresql-11-postgis-2.5 not effectively render the cluster unmigratable? I'm filing it against postgresql-common as it contains the pg_upgradecluster command. As for a resolution: I think apt-listchanges should at least warn people who have extensions installed to dump clusters before continuing the upgrade and restore them manually. Regards, Dennis.
--- End Message ---
--- Begin Message ---tags 988722 wontfix thanks On Tue, 8 Jun 2021 10:02:00 +0200 Gilles Filippini wrote: > The only solutions I can see are either to document postgis databases > manual migration (such as in [2]) or to reintroduce a minimal > postgis-2.5 runtime built against postgresql 13 to fix the scripted > migration procedure. Neither of those is happening. Not being able to us pg_upgradecluster to migrate PostGIS is a well known issue. The distribution upgrade to bullseye should be the last if postgis stays at 3.x in bookworm. If not, everything stays the same. Users need to recreate their PostGIS databases or use hacks like they always have. Upstream has removed the minor version from the filename which should help, but they still haven't fully gotten their act together. And neither have we with the heavily customized hdf5 package, I don't consider diverging that much from upstream a good thing either. Our priorities may include our users, but we can't please them all nor all the time. This is one of those times. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- End Message ---
