There is a mismatch in behaviour of a library function (returns cluster on default port) and what the program expects (null value for port if no cluster was selected)
In some circumstances, (-p specified and older version listening on default port ) this leads to the incorrect binary being run, despite comments in the (program) code saying it should be the most recent binary that is selected. The patch avoids that bug by implementing a TODO: note in the code. My reference to sid was because I saw that some variable names had been changed. I do not currently have a test machine to see which of the 2 versions I have seen is the one in testing. David Sent from my phone. Please excuse any errors On Tue, 9 Oct 2018, 15:01 Robie Basak, <1796...@bugs.launchpad.net> wrote: > Thank you for taking the time to report this bug and helping to make > Ubuntu better. > > Am I right in thinking that your problem is "If a system has a newer > version concurrently installed on a non-default port, then pg_wrapper > fails to automatically select the newer client when -p is specified"? > > I don't see anything in the documentation of pg_wrapper that says it'll > pay attention to -p specified manually. So is this a feature request > (with patch)? > > > NB. the patch will probably not apply cleanly to the current version > in debian/sid > > Please note that we won't update stable releases without first updating > the development release, since otherwise users upgrading to the next > release will subsequently find a regression. If your patch does pass > review etc, it will still be blocked from landing pending a > corresponding patch to the development release. So it's best to start > with testing/fixing the development release, get that landed, and then > backport what is required. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1796407 > > Title: > patch: make pg_wrapper select correct version for local cluster, based > on port > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1796407/+subscriptions > On 9 Oct 2018 3:01 pm, "Robie Basak" <1796...@bugs.launchpad.net> wrote: Thank you for taking the time to report this bug and helping to make Ubuntu better. Am I right in thinking that your problem is "If a system has a newer version concurrently installed on a non-default port, then pg_wrapper fails to automatically select the newer client when -p is specified"? I don't see anything in the documentation of pg_wrapper that says it'll pay attention to -p specified manually. So is this a feature request (with patch)? > NB. the patch will probably not apply cleanly to the current version in debian/sid Please note that we won't update stable releases without first updating the development release, since otherwise users upgrading to the next release will subsequently find a regression. If your patch does pass review etc, it will still be blocked from landing pending a corresponding patch to the development release. So it's best to start with testing/fixing the development release, get that landed, and then backport what is required. -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/1796407 Title: patch: make pg_wrapper select correct version for local cluster, based on port To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1796407/+subscriptions -- 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: patch: make pg_wrapper select correct version for local cluster, based on port Status in postgresql-common package in Ubuntu: New 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
