OK, thanks.
Since this isn't a bug in the documented behaviour of pg_wrapper from a
user perspective, I'm going to treat this as a new feature ("detect -p
in the command line and use it to work out which binary to run") for
now, unless someone wants to explain why this interpretation is wrong.
>From that perspective, I'm not sure this is suitable for SRU, so it will
need to go to the development release first. Unfortunately since the
patch also doesn't apply to the version currently in the development
release, it is not actionable right now.
If you could update the patch to be applicable to Debian sid, then we
could submit the patch there, and Ubuntu will in time receive the update
(if you could test/submit against Debian directly, that would be great).
In the meantime I think this bug itself is "pg_wrapper doesn't work when
-p is used" and so I'll rename the bug and triage it accordingly.
I'll also see if I can contact Martin, the original author of pg_wrapper
(AFAICT) to see if he has any comment.
** Summary changed:
- patch: make pg_wrapper select correct version for local cluster, based on port
+ pg_wrapper doesn't work when -p is used
** Changed in: postgresql-common (Ubuntu)
Status: New => Triaged
** Changed in: postgresql-common (Ubuntu)
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to postgresql-common in Ubuntu.
https://bugs.launchpad.net/bugs/1796407
Title:
pg_wrapper doesn't work when -p is used
Status in postgresql-common package in Ubuntu:
Triaged
Bug description:
Release: 16.04
pg_wrapper currently relies upon either run-time-supplied data or fixed files
which can become out of date to select the correct version of clients.
Alternatively it chooses (potentially incompatible) versions of installed
programs based on which cluster is using port 5432, even when a different port
is in use, despite code intended to default to the newest version.
The problem is that the call to user_cluster_map() returns the default port,
and thus the
condition just below this comment is not executed:
# if we only have a port, but no version here, use the latest version
# TODO: this could be improved by better argument parsing and mapping back the
# port to a cluster version/name
if (!$version and $port_specified) {
$version = get_newest_version;
}
E.g. (here shown for an old system which has 9.1 on port 5432, and 9.3 on
port 5433, similar results have been obtained on more up to date systems):
pg_dump -p 5433
pg_dump: server version: 9.3.24; pg_dump version: 9.1.24
pg_dump: aborting because of server version mismatch
Observed behaviour, ignore port value and newest version and instead choose
version from port 5432.
Expected behaviour: (as per code below comment) choose version 9.3
The supplied patch implements the TODO: above.
If a port (and no host other than localhost) has been specified, it
interrogates the configuration files to identify which cluster and version is
listening on the specified port (via -p, --port or PGPORT environment variable)
and selects those in the case that a port has been specified.
NB. the patch will probably not apply cleanly to the current version
in debian/sid, as some reworking of that has happened. Looking at that
code, however, the problem addressed here has not gone away:
user_cluster_map() still returns a port while the code in pg_wrapper
expects it not to.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1796407/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
