Re: BadRSlotError: mdb_txn_begin: MDB_BAD_RSLOT: Invalid reuse of reader locktable slot

[Howard Chu <hyc@symas.com>]

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/