I experienced errors while rearranging a portion of our project involving
largeobjects. This took an embarassingly long time for what boils down to 9
lines. In our project, I can work around it by writing a=b().c() rather than
a1=b(), a2=a1.c() (but there's only one class involved in this minimal
reproducer).
The error happens while deallocating objects which have fallen out of scope, so
it's visible in the server log but not reported to the client. Note that
testing if we're in *a* transaction isn't sufficient; I think the lo.close
shouldn't try to call lo_close or otherwise talk to the server unless it's in
the *same* transaction as when it was opened. If there's no better way,
possibly we just shouldn't call libpq lo_close at all?? Long transactions are
bad for other reasons, but that could be bad if someone accessed many LOs
within a single txn. Or, keep a per-connection list of all opened LOs, and
clear them when the transaction state changes ?
$ cat ./lo.py
import pg
def f(oid):
db.query('begin')
lo=db.getlo(oid)
lo.open(pg.INV_READ)
#lo.close() # doesn't fail if I call this
db.query('commit') # doesn't fail if this is removed
db=pg.DB('ts')
oid = db.query('SELECT loid FROM pg_largeobject LIMIT 1')[0][0]
f(oid)
$ strace -s333 -fe recvfrom python2.7 ./lo.py
...
recvfrom(4, "E\0\0\0^SERROR\0VERROR\0C42704\0Minvalid large-object descriptor:
0\0Fbe-fsstubs.c\0L119\0Rbe_lo_close\0\0", 16384, 0, NULL, NULL) = 95
$ gdb --args python2.7 ./lo.py
Breakpoint 1, lo_close (conn=0x6d61f0, fd=0) at fe-lobj.c:100
100 fe-lobj.c: No such file or directory.
in fe-lobj.c
Missing separate debuginfos, use: debuginfo-install
cyrus-sasl-lib-2.1.23-15.el6_6.2.x86_64 glibc-2.12-1.212.el6.x86_64
keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-65.el6.x86_64
libcom_err-1.41.12-24.el6.x86_64 libffi-3.0.5-3.2.el6.x86_64
libselinux-2.0.94-7.el6.x86_64 libuuid-2.17.2-12.28.el6_9.2.x86_64
nspr-4.19.0-1.el6.x86_64 nss-3.36.0-9.el6_10.x86_64
nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64 nss-util-3.36.0-1.el6.x86_64
openldap-2.4.40-16.el6.x86_64 openssl-1.0.1e-57.el6.x86_64
sssd-client-1.13.3-60.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 lo_close (conn=0x6d61f0, fd=0) at fe-lobj.c:100
#1 0x00007ffff1b93599 in large_dealloc (self=0x7ffff7f7d8f0) at pglarge.c:19
#2 0x0000003b9e8706d2 in frame_dealloc (f=Frame 0x7fffefec4910, for file
./lo.py, line 8, in f ()) at
/usr/src/debug/Python-2.7.15/Objects/frameobject.c:494
#3 0x0000003b9e8ea9ae in fast_function (f=<value optimized out>,
throwflag=<value optimized out>) at
/usr/src/debug/Python-2.7.15/Python/ceval.c:4536
#4 call_function (f=<value optimized out>, throwflag=<value optimized out>) at
/usr/src/debug/Python-2.7.15/Python/ceval.c:4469
#5 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized
out>) at /usr/src/debug/Python-2.7.15/Python/ceval.c:3083
#6 0x0000003b9e8eba5e in PyEval_EvalCodeEx (co=0x7ffff7ee8bb0, globals=<value
optimized out>, locals=<value optimized out>, args=<value optimized out>,
argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,
Justin
_______________________________________________
PyGreSQL mailing list
[email protected]
https://mail.vex.net/mailman/listinfo/pygresql
