Your message dated Sat, 10 Aug 2019 23:07:27 +0000 with message-id <e1hwasn-000amp...@fasolo.debian.org> and subject line Bug#933368: fixed in postgresql-9.6 9.6.15-0+deb9u1 has caused the Debian Bug report #933368, regarding strong vote against deleting cluster on package purge 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.) -- 933368: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933368 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: postgresql Version: 9.6+181+deb9u2 I am creating this bugreport because of a mishap that now has happened twice to me and I think it does not actually have to happen and maybe the behavior of the package should be changed. 1) At home I once tried a document management system for my private home paper work. It worked great until I did a debian upgrade of the server. Everything worked fine and I also --purge all removed packages. Then all of sudden the database was gone. After noticing that I should not have --purge the old version of postgresql I found out that I had no backups. Since then I work with paper again. Of course it is my fault, but ... 2) Yesterday at work I did a massive upgrade of all kinds of virtual machines at the same time. A lot of different services like mail, fileserver, etc. So again I ran into the pitfall that purging old packages deletes my postgresql cluster. Of course I have backups but the work of one day is lost and all employees are very happy of course. Yes I know it is my fault, but ... Here are the arguments I have against cleaning up the actual cluster files when --purge postgresql a) Compare postgresql to samba or nfs-kernel-server. When purging these packages, the files on the filesystem which the server was serving will certainly not be removed. But on postgresql they are. b) What is worse? Having files not owned by a corresponding package in /var/lib/postgresql or losing a complete database on system upgrade? c) Compare this to for example ruby gems. When doing gem install xxx as root, you will get files in /var/lib/gems/version/... Now when upgrading the system you will get a new ruby version and when installing gems, a new version directory will be built. The old one just stays there and nobody ever deletes it. Especially not the old ruby packages when you --purge them. I am sure I am not the only one who fell in this --purge trap. To say it again, of course it is my own fault, but still I think that the package should not delete the cluster on --purge. Please rethink that decision. Thanks Erik
--- End Message ---
--- Begin Message ---Source: postgresql-9.6 Source-Version: 9.6.15-0+deb9u1 We believe that the bug you reported is fixed in the latest version of postgresql-9.6, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 933...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Christoph Berg <m...@debian.org> (supplier of updated postgresql-9.6 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Thu, 08 Aug 2019 15:55:21 +0200 Source: postgresql-9.6 Binary: libpq-dev libpq5 libecpg6 libecpg-dev libecpg-compat3 libpgtypes3 postgresql-9.6 postgresql-9.6-dbg postgresql-client-9.6 postgresql-server-dev-9.6 postgresql-doc-9.6 postgresql-contrib-9.6 postgresql-plperl-9.6 postgresql-plpython-9.6 postgresql-plpython3-9.6 postgresql-pltcl-9.6 Architecture: source Version: 9.6.15-0+deb9u1 Distribution: stretch-security Urgency: medium Maintainer: Debian PostgreSQL Maintainers <team+postgre...@tracker.debian.org> Changed-By: Christoph Berg <m...@debian.org> Description: libecpg-compat3 - older version of run-time library for ECPG programs libecpg-dev - development files for ECPG (Embedded PostgreSQL for C) libecpg6 - run-time library for ECPG programs libpgtypes3 - shared library libpgtypes for PostgreSQL 9.6 libpq-dev - header files for libpq5 (PostgreSQL library) libpq5 - PostgreSQL C client library postgresql-9.6 - object-relational SQL database, version 9.6 server postgresql-9.6-dbg - debug symbols for postgresql-9.6 postgresql-client-9.6 - front-end programs for PostgreSQL 9.6 postgresql-contrib-9.6 - additional facilities for PostgreSQL postgresql-doc-9.6 - documentation for the PostgreSQL database management system postgresql-plperl-9.6 - PL/Perl procedural language for PostgreSQL 9.6 postgresql-plpython-9.6 - PL/Python procedural language for PostgreSQL 9.6 postgresql-plpython3-9.6 - PL/Python 3 procedural language for PostgreSQL 9.6 postgresql-pltcl-9.6 - PL/Tcl procedural language for PostgreSQL 9.6 postgresql-server-dev-9.6 - development files for PostgreSQL 9.6 server-side programming Closes: 911940 932247 933368 Changes: postgresql-9.6 (9.6.15-0+deb9u1) stretch-security; urgency=medium . * New upstream security release. + Fixes regression in ALTER TABLE on multiple columns. (Closes: #932247) . + Require schema qualification to cast to a temporary type when using functional cast syntax (Noah Misch) . We have long required invocations of temporary functions to explicitly specify the temporary schema, that is pg_temp.func_name(args). Require this as well for casting to temporary types using functional notation, for example pg_temp.type_name(arg). Otherwise it's possible to capture a function call using a temporary object, allowing privilege escalation in much the same ways that we blocked in CVE-2007-2138. (CVE-2019-10208) . * On purge, ask the user if they want to remove clusters. (Closes: #911940, #933368) Checksums-Sha1: 96b672b2c0aa809b9a88c185e804219b8ffdb488 3698 postgresql-9.6_9.6.15-0+deb9u1.dsc 2375ff8387ed746093f575f2cc69a2dabb5d15ce 18799121 postgresql-9.6_9.6.15.orig.tar.bz2 3a5f1cd414fdc8b2a725aa226fe1aa7edb3d850f 29760 postgresql-9.6_9.6.15-0+deb9u1.debian.tar.xz Checksums-Sha256: 01496f5c6784e3e1f3887df7fbbd2b76048752ded483e3595cb830ab4f208b41 3698 postgresql-9.6_9.6.15-0+deb9u1.dsc 3cd9fe9af247167f863030842c1a57f58bdf3e5d50a94997d34a802b6032170a 18799121 postgresql-9.6_9.6.15.orig.tar.bz2 06906589c9b2978ac9e423023d5adac937eb2185728d638be879108d2808d9ee 29760 postgresql-9.6_9.6.15-0+deb9u1.debian.tar.xz Files: dcc8d364a2d7cf708cc1335ca17ea2ef 3698 database optional postgresql-9.6_9.6.15-0+deb9u1.dsc efb0bfbd9926f9491543e5cafd30ddd7 18799121 database optional postgresql-9.6_9.6.15.orig.tar.bz2 4a2dc643c307bcc6df6e9e4b942a69fb 29760 database optional postgresql-9.6_9.6.15-0+deb9u1.debian.tar.xz -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAl1MNZoACgkQTFprqxLS p675hg//ZKPavmjsvRwmx8I5jEJMQcGEh615MePwAW+ccxkIXEtn1qLbK1xieqju QWwHfpyJNTVPmB9/WQkCo8AkK0AoPcmpsnVI9bQvVYXQlxFkwsdJ3ct/l6k/TkdO TEwLkWXrgii+5kUPuDuytpiVfgdNElR6icJK2X8NLeoTj7IQvOEZXsZTjRklanLv FhViuMB3fyichDcmOhu1aUD5G50oc9mkNzl8SJueaMVeVKPJ5YyNn7RwWrQPId4Z X96hBv8AkF58U8rNGb8uUspPvoeeb4Z1/Nj6OdIUGaNelB0mL0jA1lNbdyXVnwcY LTo3qYI+zDCzmuKQrUnaLtJXJS2Du5PC+Ih3Bj9m10AweQJIH5EbyqEOxdXPxwsT A/SnhaX/e9N9hshyqH/pPlJPYHGNwFmkChBU0Sm/TaOw20UPRcregVPzAhJ5j0XC hEYZk6OkNeI6EkH0Q4Ec0kLQt7lRj5/Miirlso6C33tPEfX/xRS9NqCOTI2J2BRq imvs2C0l/W2zBmm50ARFqKNfzlKDqUpKDsIl+kvlr7ciOWfaL2nSmrQs7KY5iQMC v2TqwHBwpJu8siJ6StVCcIeT7O8iCva57bWfNKEcnyTJtUHSa8E+VgAmKYjzSNC4 MAna6EtHTpLEkT2NeswVcKnjL5XF1EKEgSUK+NKzvQMlX0YnQXE= =MnUx -----END PGP SIGNATURE-----
--- End Message ---
