Luke Kenneth Casson Leighton wrote:
garbage collection occurs periodically, at any time the
interpreter
feels like it
(afaik). so, the scenario under consideration is therefore that a
cursor gets closed
at random points, well after its txn has been closed.
however if the c api is reflected in the python layer then correspondingly the
cursor could not interfere with a txn.
the only other possibility under consideration is that the python
process has been
killed unexpectedly (kill -9) and has left the database in an abnormal state.
Not possible; the database structure is inherently incorruptible. kill -9
won't do anything to it.
looking at the application logs that i have available (qty one
only
at the moment)
i do note that the application appears to have just undergone a restart...
You're talking about a database being accessed by only a single process; the
lock table is reinitialized whenever a process opens it and no other processes
already have it open. As such, no locktable elements from a previous crash
will ever affect the running process.
i'll have to have a closer look but would that be causing any problems (esp
with the arguments to speed up access such as sync=False etc.)
Nope. sync is irrelevant for application-level crashes, all the data goes into
the OS buffer cache regardless. sync=False will likely leave you a corrupted
database if the OS or hardware crashes, but not if the application process
crashes.
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/