Your message dated Wed, 22 Jan 2025 10:35:40 +0100
with message-id <[email protected]>
and subject line Re: Bug#986186: postgresql-common: pg_dump does not talk to
the last major version (11): Error: PostgreSQL version 9.6 is not installed
has caused the Debian Bug report #986186,
regarding pg_wrapper: Include -p NNNN argument in port selection
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.)
--
986186: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986186
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: postgresql-common
Version: 225
Severity: normal
Dear Maintainer,
I have upgraded this buster system to bullseye. I did not do anything
postgresql related during the upgrade and phppgadmin kept working, so I
kept entering data with that. I think both clusters (11 and 13) were
running at the same time, and phppgadmin connected to 11.
Now I would like to make a database dump before I upgrade the cluster.
The postgresql 9.6 directory is still present, and postgresql-11 is
still installed and running:
$ pg_lsclusters
Ver Cluster Port Status Owner Data directory
Log file
9.6 main 5432 down,binaries_missing postgres /var/lib/postgresql/9.6/main
/var/log/postgresql/postgresql-9.6-main.log
11 main 5433 online postgres /var/lib/postgresql/11/main
/var/log/postgresql/postgresql-11-main.log
13 main 5434 online postgres /var/lib/postgresql/13/main
/var/log/postgresql/postgresql-13-main.log
I can connect to the version 11 cluster with psql -p 5433 my_database, but when
I
run pg_dump -p 5433 my_database, I get
Error: PostgreSQL version 9.6 is not installed
After dropping 9.6 with pg_dropcluster this works as expected, but I
think it would be preferable if this would not be necessary.
BTW, is there work underway to provide a postgresql specific paragraph
in the bullseye release notes? I am not very experienced with
postgresql, but would be willing to help writing/proof reading/testing.
Johannes
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages postgresql-common depends on:
ii adduser 3.118
ii debconf [debconf-2.0] 1.5.75
ii lsb-base 11.1.0
ii perl 5.32.1-3
ii postgresql-client-common 225
ii ssl-cert 1.1.0
ii ucf 3.0043
Versions of packages postgresql-common recommends:
ii e2fsprogs 1.46.2-1
ii logrotate 3.18.0-2
Versions of packages postgresql-common suggests:
ii libjson-perl 4.03000-1
-- Configuration Files:
/etc/apt/apt.conf.d/01autoremove-postgresql changed [not included]
-- debconf information:
* postgresql-common/obsolete-major:
postgresql-common/catversion-bump:
postgresql-common/ssl: true
--- End Message ---
--- Begin Message ---
Version: 246
Re: Johannes Ranke
> > It would probably be a good idea to include the "-p 5433" argument in
> > the cluster selection algorithm - so far I refrained from doing that
> > in order not to create more corner cases, but I guess it just makes
> > sense. (And granted, -p 54NN is also how I select my local version NN
> > cluster here.) It's too late to do that for bullseye, though.
>
> I'm glad you like the idea. This will make it more intuitive, as it will be
> consistent with psql in this respect.
Fwiw, this was implemented in 2022, but this bug was never closed.
Thanks for the suggestion!
Christoph
--- End Message ---
