pg_createcluster silently deletes existing cluster
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
postgresql-common (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Hardy |
Fix Released
|
High
|
Martin Pitt | ||
Lucid |
Fix Released
|
High
|
Martin Pitt |
Bug Description
Binary package hint: postgresql-common
# Linux <DELETED> 2.6.32-25-server #44-Ubuntu SMP Fri Sep 17 21:13:39 UTC 2010 x86_64 GNU/Linux
# ii postgresql-common 106 PostgreSQL database-cluster manager
When running pg_createcluster on an already existing cluster, the END handler completely deletes the existing cluster
without any warnings or notices, if the existing cluster is not running. This is highly dangerous and IMO a major bug.
To reproduce:
l# pg_lsclusters
Version Cluster Port Status Owner Data directory Log file
8.4 main 5432 down postgres /var/lib/
# pg_createcluster 8.4 main
Error: cluster configuration already exists
# pg_lsclusters
Version Cluster Port Status Owner Data directory Log file
# pg_createcluster 8.4 main
Creating new cluster (configuration: /etc/postgresql
Moving configuration file /var/lib/
Moving configuration file /var/lib/
Moving configuration file /var/lib/
The culprit:
nl /usr/bin/
378 END {
379 # clean up cruft if something went wrong
380 if (!$createsuccess && defined $version && defined $cluster) {
381 system "pg_dropcluster $version $cluster 2>/dev/null";
382 exit 1;
383 }
384 }
Possible solution:
See attached patch
tags: | added: patch |
Thanks! This has already been fixed in version 111, which is in maverick and natty:
postgresql-common (111) unstable; urgency=high
* Urgency high since this fixes two RC bugs. supported- versions: Be more robust against lsb_release failing, e. supported- versions: Drop check for /etc/debian_version if postgresql- common. preinst. (Closes: #597654)
* t/030_errors.t: Check that pg_createcluster leaves the original one intact
if the cluster already exists, also when the original one is not running.
This reproduces #597097.
* pg_createcluster: Be more careful with cleaning up the created cluster if
an error occurs: Do not start the cleanup until we actually passed our
sanity checks and created files for the new cluster. Before, it would
erroneously remove an already existing cluster on a sanity check fail, if
that cluster happened to not be running at the time. (Closes: #597097)
* debian/
g. in the case where it is not fully configured yet. (Closes: #597561)
* debian/
lsb_release is not working/existing. Derivatives have debian_version as
well, and we don't actually evaluate it, so just print a meaningful error
message and go with the default versions.
* debian/rules: Put init script priority back to S19/K21 to match the
previous postgresql-8.4 init script. Fix the priorities on upgrade in
debian/
-- Martin Pitt <email address hidden> Wed, 22 Sep 2010 12:04:00 +0200
For lucid I propose to SRU the patch; it contains a test case and is pretty straightforward:
http:// bazaar. launchpad. net/~pitti/ postgresql/ common/ revision/ 1024