pythonlmdb

lmdb.BadRslotError: mdb_txn_begin: MDB_BAD_RSLOT: Invalid reuse of reader locktable slot?


I've been experimenting with nearest neighbor algorithm for images with the style presented in this post (i.e. goal is to see how many nearly similar images there is). After getting the example adapted to my case running, I have seen couple of times the error "lmdb.BadRslotError: mdb_txn_begin: MDB_BAD_RSLOT: Invalid reuse of reader locktable slot" , and wondering what is the cause?

My hypothesis is that it was caused by opening the (same) lmdb twice in the same run (at least it hasn't appeared since fixing that), but not totally sure. One of the few search hits is given in another forum, but the answer is not definite.

So the error came from the .begin statement:

fn_lmdb = fn + '.lmdb'  # stores word <-> id mapping
env = lmdb.open(fn_lmdb, map_size=int(1e9))

with env.begin() as txn:
    ... 

At the moment after I moved open next to the begin, the error has not yet appeared, but not sure if I fixed the cause or just a symptom... Have you stumbled to this one, and what was the solution?


Solution

  • I've encountered the same issue, running with multiprocesses in Python. Since this is perhaps the only related question with this error in SO it wasn't easy to find a solution. Eventually I've reached this pull request on github and following the documentation made this change in my code:

    lmdb.open(db_dir, create=False, subdir=True, readonly=True, lock=False)
    

    lock: If False, don’t do any locking. If concurrent access is anticipated, the caller must manage all concurrency itself. For proper operation the caller must enforce single-writer semantics, and must ensure that no readers are using old transactions while a writer is active. The simplest approach is to use an exclusive lock so that no readers may be active at all when a writer begins.

    My transactions are readonly, so that solution works for me.

    I don't know what was causing the issue, my understanding according to the documentation is that the locks in the lock file aren't managed by the lmdb package or Python, and the transactions are simply trying to write to the same place in the file.

    Hope it may help someone, since the fix I haven't encountered this problem again. So at the moment it seems to work.