Dropping dbi in nested aborted txn invalidates the dbi in the parent txn

[capr]

Hi Leonid, quick question. From testing it seems that dropping a dbi in a nested aborted txn invalidates the dbi in the parent txn. Even if I reopen or recreate the dbi inside the nested txn, the dbi is still invalid in the parent txn after. Is this behavior expected? I get that this is an edge case but I'm writing a language binding and I'd like the semantics of an aborted txn to be such that it can't mess up the context around it. It seems like the only way to fix this in user code is to track dropped dbs and reopen them on abort. Does that sound right?

[erthink]

In short, such a shortcoming exists, and no rational way has yet been found to eliminate it.

Historically, in LMDB, incomplete and asymmetric isolation of the state of DBIs between transactions:

• when creating a named table, until commit it exists only inside the transaction, so its DBI cannot be seen outside until the commit;
• however, when dropping a named table, its DBI has to be compelled closed for all transactions, including reads.

Such design was done in LMDB to simplify implementation. Really simple and stupidly naive as possible.
Initially, I did not fix this, because it did not interfere and there were a lot of much more serious problems.

It is difficult to fix this now, as it will lead to incompatibilities with already written code, and most importantly, it is likely to cause difficult-to-detect regressions.

I think I'll come back to this question, but I don't have time for that yet.