Your message dated Tue, 09 Jul 2019 14:47:56 +0000
with message-id <e1hkrpq-000aqo...@fasolo.debian.org>
and subject line Bug#931635: fixed in postgresql-common 203
has caused the Debian Bug report #931635,
regarding pg_upgradecluster writes data_directory to postgresql.auto.conf, and
gets confused by it on the next upgrade [DATA LOSS]
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.)
--
931635: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931635
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: postgresql-common
Version: 200
Severity: critical
Tags: buster sid
In postgresql-common 200, pg_upgradecluster learned how to copy the
contents of postgresql.auto.conf (where ALTER SYSTEM stores its data;
#810615).
Internally, adapt_conffiles() gets invoked twice, once for
postgresql.conf and once for postgresql.auto.conf. This function is
also responsible for setting data_directory in the new cluster.
Unfortunately, it does this both for postgresql.conf (correct) and
postgresql.auto.conf (where ALTER SYSTEM itself refuses to set
data_directory, but having a file with it is syntactically ok).
At this point, both clusters operate normally, and no harm is done
because postgresql.auto.conf contains the correct data_directory
setting.
However, if this cluster gets upgraded *again*, this extra
postgresql.auto.conf setting will confuse the "update config file"
logic in postgresql-common's PgCommon.pm. The effect is that on the
second upgrade, the new data_directory setting for the 3rd cluster
will be written to the postgresql.auto.conf file of the *2nd* cluster.
(And the 3rd cluster has a verbatim copy of the old postgresql.auto.conf
from the 2nd cluster.) At this point, all three clusters still operate
normally because pg_ctlcluster/pg_ctl can still launch the clusters,
despite the bad data_directory settings in postgresql.auto.conf.
Symptoms of the problem at this point are:
* `pg_lsclusters` shows the wrong Data directory for the 2nd and 3rd cluster
Ver Cluster Port Status Owner Data directory Log file
9.5 main 5433 down postgres /var/lib/postgresql/9.6/main
/var/log/postgresql/postgresql-9.5-main.log
9.6 main 5432 online postgres /var/lib/postgresql/9.5/main
/var/log/postgresql/postgresql-9.6-main.log
* `ps` shows the wrong data directory on the postgres command line:
/usr/lib/postgresql/9.6/bin/postgres -D /var/lib/postgresql/9.5/main -c
config_file=/etc/postgresql/9.6/main/postgresql.conf
The really bad problem now using `pg_dropcluster` will wipe the data
directory OF THE WRONG CLUSTER. Oops. (And sorry.)
I have a patch ready, including testsuite coverage. I'll also upload a
200+deb10u2 package to buster-proposed-updates.
Christoph
--- End Message ---
--- Begin Message ---
Source: postgresql-common
Source-Version: 203
We believe that the bug you reported is fixed in the latest version of
postgresql-common, 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 931...@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-common 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: Tue, 09 Jul 2019 16:16:57 +0200
Source: postgresql-common
Architecture: source
Version: 203
Distribution: unstable
Urgency: medium
Maintainer: Debian PostgreSQL Maintainers <team+postgre...@tracker.debian.org>
Changed-By: Christoph Berg <m...@debian.org>
Closes: 507133 931635
Changes:
postgresql-common (203) unstable; urgency=medium
.
DATA LOSS WARNING: pg_upgradecluster from postgresql-common 200 .. 202 will
corrupt the data_directory setting when used *twice* to upgrade a cluster
(e.g. 9.6 -> 10 -> 11). This update fixes the original problem, and also
heals affected clusters on the next upgrade. No additional steps are
required.
.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931635
.
* pg_createcluster: Allow clusters with owner gid 0. (salsa-ci uses that.)
* pg_createcluster: If there are --auth options in createcluster.conf's
initdb_options, don't update pg_hba.conf.
* pg_upgradecluster: Don't accidentally set (the wrong!) data_directory in
postgresql.auto.conf. (Closes: #931635)
* PgCommon.pm: Ignore data_directory when set in postgresql.auto.conf.
* pg_upgradecluster: Delete data_directory from postgresql.auto.conf in new
cluster.
* pg_upgradecluster: Use a tempfile instead of replacing the original
pg_hba.conf file during upgrades.
* pg_upgradecluster: With --keep-port, leave old cluster on original port.
(Closes: #507133)
* pg_ctlcluster: For consistency with systemctl, also accept action before
cluster name: "pg_ctlcluster start 11 main".
* pg_ctlcluster: Use `psql -w` to avoid flooding the log with errors when
the cluster was configured for password authentication on local
connections. Patch by Evgeny, thanks!
* debian/tests: Do full testsuite run. Previously the full testsuite was
only running from the postgresql-NN server package.
* t/135_pg_virtualenv.t: Don't fail if fakeroot is not present.
Checksums-Sha1:
2186ebbd62d67131f1fa31e2525cb9c1bd5cfda9 2424 postgresql-common_203.dsc
fb3e108282b25ecb18a4e3bcd3ea6171cdca447a 214316 postgresql-common_203.tar.xz
20bea4e430e2b1ed4d575783eb71e86ed8d45010 6009
postgresql-common_203_source.buildinfo
Checksums-Sha256:
eba3702ace5372eb24aad436c9f683aee569266b8e5ff1a7d2e53d0f697f81c0 2424
postgresql-common_203.dsc
c02db7ad77f37a43781a8568f9731e1671952424dbbc8b60c9bc8ce81be0042c 214316
postgresql-common_203.tar.xz
8d7ce96e49ba84f789fb049c8b354b1c6f1866757e7cdb48cc8088fcef5ffda9 6009
postgresql-common_203_source.buildinfo
Files:
9c4b039e600858a4be0105e0c15c5e04 2424 database optional
postgresql-common_203.dsc
fc865605c7d13e19874e6292bc3847dd 214316 database optional
postgresql-common_203.tar.xz
c8fc939b1ff4dcba30d6771587b6835d 6009 database optional
postgresql-common_203_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEXEj+YVf0kXlZcIfGTFprqxLSp64FAl0kpC8ACgkQTFprqxLS
p657Fw/+OnpgewG/48loYWiJC+r5lxTCE+H42cZ82dFsAQzued+XyzzYdgp/ggD8
gQCOAGxTEELCkNio3l69YBlbfHj8OIV0kk+QYt1yWZ45fVICU368muYHGUkm1C6t
Pro1PLPUDHZU68Kbr+KrkL4sjYmb+/IUDqiU0UawD/7HV/Rxk2RDBd/kNXDoDGJx
jAVIFqjNxB1pbnsJOHTI1gYjPD+FdknWPgQtR/WgUYF5cZM8H5JUR6w8a2ZKHlNY
av+eA/08zCCX2iObl67mUGbRzN+a5PdaZPHjGjKFIRLiZAxZZB3gY2rguLE4h+Sj
t5Dg4PRrtTSp8GxpK4lrhAAfUb75QnSr5XlzmclJoKxDcab8L2dcLhPbEWI+7jM6
x+9pFYwpqWTp7Di3VSLmchiOUGHxb4vGfk9aGOEXyfR1aqjRqxArnevHPj4XfTGi
dXWjelARbJsUq88nGQe8luOz/ubnVF3p6En5cL06mBrGss+/KD5pLr8/UZltUmwm
sLjuMHzQLt/NkHuKdaYhs6IOt+xtsUzbnUPt8l3M7tBVYP7ckZd6+y/yj5F0Asm9
CHoQJbLuKxVddW8NbXnGRnNYjRepUxU8UmY7fswvvxHcSC4AbxIvjuJlDpvWJhhf
Q4wHUNrGUa62bjD3YXhuV34K5mI9WhiknQ9cS6rH3W8LFU+vlDg=
=CrEe
-----END PGP SIGNATURE-----
--- End Message ---
