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.