On 3/14/20 9:12 AM, Karsten Hilbert wrote:
Dear Adrian,
unfortunately, we don't have direct contact with the reporter
(only via our mailing list and they haven't answered so far).
How was psycopg2 installed?
Given they are running a "standard" Debian/Unstable with a
Debian package of GNUmed installed and the matching psycopg2
package version
psycopg2 module version: 2.8.4 (dt dec pq3 ext lo64)
I suspect they apt-get install'ed it. Which assumption seems
supported by the package file string in:
PostgreSQL via DB-API module "<module 'psycopg2' from
'/usr/lib/python3/dist-packages/psycopg2/__init__.py'>": API level 2.0, thread safety 2,
parameter style "pyformat"
The one thing that's odd is that the Python version
Python 3.7.6 (default, Jan 19 2020, 22:34:52) <\n>[GCC 9.2.1 20200117]
on linux (posix)
does not match what's available from Debian:
python3:
Installiert: 3.7.3-1
Installationskandidat: 3.7.3-1
Versionstabelle:
3.8.2-1 500
500 https://deb.debian.org/debian unstable/main i386 Packages
3.7.5-3 500
500 https://deb.debian.org/debian bullseye/main i386 Packages
*** 3.7.3-1 990
990 https://deb.debian.org/debian buster/main i386 Packages
100 /var/lib/dpkg/status
What is the code being run when the errors are thrown?
It happens (two reports so far) at different stages during
the bringup phase of the GNUmed client. The code being run is
the same, but the time of occurrence is different.
case 1:
select vco.value from cfg.v_cfg_opts_numeric vco where vco.owner =
CURRENT_USER and vco.workplace = %(wp)s and vco.option = %(opt)s and vco.cookie
is null limit 1
case 2:
select _(message) from cfg.db_logon_banner
where _() translates "message". This is the Python code being
run (the place of error marked with xxxxx):
Went through the function and the attached logs from the OP. I do not
pretend to understand all of what the logs are showing. Still I do not
see anything that stands out to me.
--
Adrian Klaver
adrian.kla...@aklaver.com
