Your message dated Mon, 22 Jun 2020 12:58:24 -0400
with message-id <4076768.TLDnZDVXE1@zini-1880>
and subject line Re: Bug#960499: python3-psycopg2: fails with
"psycopg2.OperationalError: insufficient data in "T" message"
has caused the Debian Bug report #960499,
regarding python3-psycopg2: fails with "psycopg2.OperationalError: insufficient
data in "T" message"
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.)
--
960499: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960499
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: python3-psycopg2
Version: 2.7.7-1
Severity: important
Dear Maintainers,
users report the following exception:
Traceback (most recent call last):
File "/usr/share/gnumed/Gnumed/wxpython/gmGuiMain.py", line 3457, in OnInit
if not self.__verify_praxis_branch():
File "/usr/share/gnumed/Gnumed/wxpython/gmGuiMain.py", line 3687, in
__verify_praxis_branch
banner = praxis.db_logon_banner
File "/usr/share/gnumed/Gnumed/business/gmPraxis.py", line 500, in
_get_db_logon_banner
rows, idx = gmPG2.run_ro_queries(queries = [{'cmd': 'select _(message) from
cfg.db_logon_banner'}])
File "/usr/share/gnumed/Gnumed/pycommon/gmPG2.py", line 1547, in
run_ro_queries
curs.execute(query['cmd'], args)
File "/usr/lib/python3/dist-packages/psycopg2/extras.py", line 142, in execute
return super(DictCursor, self).execute(query, vars)
psycopg2.OperationalError: insufficient data in "T" message
which looks like a problem at the Python3/C boundary of psycopg2 or even
in the C part of psycopg2 below Python itself (or even libpq ? - unlikely).
This happens on the following system:
Platform: uname_result(system='Linux', node='X1slapper',
release='5.4.0-29-generic', version='#33-Ubuntu SMP Wed Apr 29 14:32:27 UTC
2020', machine='x86_64', processor='x86_64')
Python 3.8.2 (default, Apr 27 2020, 15:53:34) <\n>[GCC 9.3.0] on linux
(posix)
lsb_release: {'ID': 'Ubuntu', 'DESCRIPTION': 'Ubuntu 20.04 LTS',
'RELEASE': '20.04', 'CODENAME': 'focal'}
threading: sys.thread_info(name='pthread', lock='semaphore',
version='NPTL 2.31')
psycopg2 module version: 2.8.4 (dt dec pq3 ext lo64)
PostgreSQL via DB-APImodule "<module 'psycopg2' from
'/usr/lib/python3/dist-packages/psycopg2/__init__.py'>": API level 2.0, thread
safety 2, parameter style "pyformat"
libpq version (compiled in): 120002
libpq version (loaded now) : 120002
The failing query is rather simple (and probably immaterial):
select _(message) from cfg.db_logon_banner
where _() is a plpgsql function providing a translation lookup.
The very same code works just fine on Python 3.7 / psycopg2 2.7.
Any ideas where else to look ?
Karsten
-- System Information:
Debian Release: 10.4
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable-debug'), (500,
'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 5.6.0-trunk-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-psycopg2 depends on:
ii libc6 2.28-10
ii libpq5 11.7-0+deb10u1
ii python3 3.7.3-1
python3-psycopg2 recommends no packages.
Versions of packages python3-psycopg2 suggests:
ii python-psycopg2-doc 2.7.7-1
-- no debconf information
--- End Message ---
--- Begin Message ---
On Monday, June 22, 2020 8:48:43 AM EDT Karsten Hilbert wrote:
> On Wed, May 13, 2020 at 09:13:42AM -0400, Scott Kitterman wrote:
> > > Any ideas where else to look ?
> >
> > It would surprise me if this turned out to be relevant, but since it's
> > probably easy to check, I'll toss it out there:
> >
> > In psycopg2 2.8 the function where the traceback is triggered has been
> > modified to use OrderedDict.
> >
> > "/usr/lib/python3/dist-packages/psycopg2/extras.py", line 142, in
> > execute return super(DictCursor, self).execute(query, vars)
> >
> > It looks like the commit where that change was made it pretty self
> > contained [1]. You might try putting the 2.7 version of DictCursor back
> > (reverting that commit) and see if the problem persists.
> >
> > It's kind of a shot in the dark, but one has to start somewhere.
>
> It turned out to be an unholy interaction between threads
> inadvertently sharing a connection. Using a connection per
> thread solves the issue.
>
> However, the strange parts:
>
> 1) The very same code (sharing the connection between
> threads) _does_ work with psycopg2 2.7.
>
> 2) psycopg2 states that sharing connections among threads is
> considered to be safe (threadsafety=2). To note, the threads
> do _not_ share cursors.
>
> At any rate, as far as GNUmed is concerned, the issue has
> been fixed or, per(!)spectively, worked around so the bug can
> be closed.
>
> Maybe one cannot hold open cursors concurrently on the a
> transaction shared by threads.
Thanks. Closing. If you can produce a simple reproducer for the problem, I
would suggest submitting it upstream.
Scott K
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
_______________________________________________
Python-modules-team mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
