Your message dated Wed, 12 Mar 2025 14:22:13 +0100 with message-id <[email protected]> and subject line Re: Bug#992955: postgresql-common: add explicit confirmation to pg_dropcluster has caused the Debian Bug report #992955, regarding postgresql-common: add explicit confirmation to pg_dropcluster 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 [email protected] immediately.) -- 992955: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992955 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: postgresql-common Version: 225 Severity: normal Tags: patch Dear Maintainers, While upgrading to bullseye, probably because I was not paying enough attention but maybe also in relation with #943788 (README.Debian: pg_upgradecluster, again suggests to drop active cluster), I was bitten hard by having dropped my active cluster with my data (and fortunately could restore from a few hours old dump). I concede I could have inferred from the word 'drop' what was going to happen. However I would have expected that such a destructive operation would have warned me and ask for my explicit confirmation. I think integrating the below patch would raise the awareness of clueless hobby users like me. Please excuse my perl, as I am not fluent in this language. Thanks, Alex --- a/pg_dropcluster +++ b/pg_dropcluster @@ -62,6 +62,13 @@ if (cluster_exists $version, $cluster) { } $c = $info{'configdir'}; $startconf = $info{'start'}; + + my $cluster_data_size = (split /\s+/, `du -h --max-depth=0 $info{'pgdata'}`)[0]; + print "Warning: This will DELETE cluster conf, data and logs PERMANENTLY.\n"; + print "This is about $cluster_data_size of data.\n"; + print "Please input 'YES' to confirm. "; + my $confirmation = <STDIN>; + $confirmation eq "YES\n" or error 'Aborting due to lack of confirmation.' } else { $c = "/etc/postgresql/$version/$cluster"; -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postgresql-common depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.77 ii lsb-base 11.1.0 ii perl 5.32.1-5 ii postgresql-client-common 225 ii ssl-cert 1.1.0+nmu1 ii ucf 3.0043 Versions of packages postgresql-common recommends: ii e2fsprogs 1.46.4-1 ii logrotate 3.18.1-2 Versions of packages postgresql-common suggests: ii libjson-perl 4.03000-1 -- debconf information: postgresql-common/catversion-bump: postgresql-common/ssl: true postgresql-common/obsolete-major:
--- End Message ---
--- Begin Message ---Version: 269 Re: Alexandre Rossi > While upgrading to bullseye, probably because I was not paying enough > attention but maybe also in relation with #943788 (README.Debian: > pg_upgradecluster, again suggests to drop active cluster), I was bitten > hard by having dropped my active cluster with my data (and fortunately > could restore from a few hours old dump). Hi, the package mechanics have been changed to not create a new cluster if there is already an existing one, so the README.Debian instructions no longer tell you about dropping anything. Christoph
--- End Message ---
