Processed: Re: Bug#886742: postgresql-9.4-postgis-2.1 missing in stretch
Processing commands for cont...@bugs.debian.org: > severity 886742 normal Bug #886742 [postgresql-9.4-postgis-2.1] postgresql-9.4-postgis-2.1 missing in stretch Severity set to 'normal' from 'critical' > thanks Stopping processing here. Please contact me if you need assistance. -- 886742: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886742 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#886742: [INFO] Bug#886742: postgresql-9.4-postgis-2.1 missing in stretch
On Tue, Jan 09, 2018 at 02:37:44PM +0100, Jürgen Fuchsberger wrote: > >> What did you try, and what didn't work? > > > > Probably pg_upgradecluster, and that is not supported for databases with > > the postgis extension. > > > Exactly. Just wanted to point out that upgrading was no possibility > either, the actual problem was that the database could not be accessed > or dumped after the upgrade. While ideally one could use hook scripts to manage such kind of extensions I would not try that approach in any case. A Postgis hard upgrade is generally a trial-and-error nightmare^Wexperience and it depends on languages, extensions, encodings. Last time, I had to perform a series of ad hoc setups before trying the restore. I strongly suggest to run both servers and extensions on the host in order to run a successfully shop upgrade later. That is definitively possible, I have at least one server still running both 8.4 and 9.4 with required Postgis extensions. -- Francesco P. Lovergine
Bug#886742: postgresql-9.4-postgis-2.1 missing in stretch
On 2018-01-09 14:16, Bas Couwenberg wrote: > On 2018-01-09 14:08, Christoph Berg wrote: >> Re: Juergen Fuchsberger 2018-01-09 >> <20180109130149.17725.10545.report...@wegc203058.uni-graz.at> >>> Due to missing postgresql-9.4-postgis-2.1 in stretch, a postgis enabled >>> database becomes corrupt when upgrading from jessie to stretch since >>> the required postgis libraries are missing. This can cause serious data >>> loss, because once upgraded to stretch, the postgis data can't be >>> accesed nor dumped (Database gives error "could not access file >>> "$libdir/postgis-2.1": no such file or directory"). >> >> Could you append the apt output to this bug? Namely, which packages >> got removed? (/var/log/apt/term.log) >> >>> Also upgrading the database to postgresql-9.6 does not work. >> >> What did you try, and what didn't work? > > Probably pg_upgradecluster, and that is not supported for databases with > the postgis extension. > Exactly. Just wanted to point out that upgrading was no possibility either, the actual problem was that the database could not be accessed or dumped after the upgrade. Juergen
Bug#886742: postgresql-9.4-postgis-2.1 missing in stretch
On 2018-01-09 14:08, Christoph Berg wrote: Re: Juergen Fuchsberger 2018-01-09 <20180109130149.17725.10545.report...@wegc203058.uni-graz.at> Due to missing postgresql-9.4-postgis-2.1 in stretch, a postgis enabled database becomes corrupt when upgrading from jessie to stretch since the required postgis libraries are missing. This can cause serious data loss, because once upgraded to stretch, the postgis data can't be accesed nor dumped (Database gives error "could not access file "$libdir/postgis-2.1": no such file or directory"). Could you append the apt output to this bug? Namely, which packages got removed? (/var/log/apt/term.log) Also upgrading the database to postgresql-9.6 does not work. What did you try, and what didn't work? Probably pg_upgradecluster, and that is not supported for databases with the postgis extension. See my reply to #886738 and http://lists.alioth.debian.org/pipermail/pkg-grass-devel/2017-November/064317.html For more info, see: http://blog.cleverelephant.ca/2016/08/postgis-upgrade.html http://www.bostongis.com/blog/index.php?/archives/268-Using-pg_upgrade-to-upgrade-PostGIS-without-installing-an-older-version-of-PostGIS.html As long as the postgis package is built for a single postgresql version, upgrades cannot be supported. When using postgis on Debian, distribution upgrades involve recreating the postgis databases as pg_upgradecluster will fail. Kind Regards, Bas
Processed: Re: Bug#886742: postgresql-9.4-postgis-2.1 missing in stretch
Processing control commands: > tags -1 moreinfo Bug #886742 [postgresql-9.4-postgis-2.1] postgresql-9.4-postgis-2.1 missing in stretch Added tag(s) moreinfo. -- 886742: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886742 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#886742: postgresql-9.4-postgis-2.1 missing in stretch
Control: tags -1 moreinfo Re: Juergen Fuchsberger 2018-01-09 <20180109130149.17725.10545.report...@wegc203058.uni-graz.at> > Due to missing postgresql-9.4-postgis-2.1 in stretch, a postgis enabled > database becomes corrupt when upgrading from jessie to stretch since > the required postgis libraries are missing. This can cause serious data > loss, because once upgraded to stretch, the postgis data can't be > accesed nor dumped (Database gives error "could not access file > "$libdir/postgis-2.1": no such file or directory"). Could you append the apt output to this bug? Namely, which packages got removed? (/var/log/apt/term.log) > Also upgrading the database to postgresql-9.6 does not work. What did you try, and what didn't work? Christoph
Bug#886742: postgresql-9.4-postgis-2.1 missing in stretch
Package: postgresql-9.4-postgis-2.1 Severity: critical Justification: causes serious data loss Dear Maintainer, Due to missing postgresql-9.4-postgis-2.1 in stretch, a postgis enabled database becomes corrupt when upgrading from jessie to stretch since the required postgis libraries are missing. This can cause serious data loss, because once upgraded to stretch, the postgis data can't be accesed nor dumped (Database gives error "could not access file "$libdir/postgis-2.1": no such file or directory"). Also upgrading the database to postgresql-9.6 does not work. -- System Information: Debian Release: 8.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/20 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
