Hallvard B Furuseth wrote:

hyc@symas.com writes:

...

...

      bdb_unlocked_cache_return_entry_r(&bdb->bi_cache, p );

(...)

Releasing entries is somewhat irrelevant, since all locks are released when the transaction commits. Note that this function is a no-op in proto-bdb.h. All of those statements are just relics from the first entry cache design, before we switched to using BDB locks for everything.

OK. Does that apply to bdb_cache_return_entry_r( bdb, oe,&lock ); after bdb_cache_add( bdb, ei, op->ora_e,&nrdn, rlocker,&lock ); failed TXN_COMMIT( ltid, 0 ); too? bdb_cache_return_entry_r() is not a no-op.

No, that call obviously matters. But I'm not sure that this commit can ever actually fail, or what to do about it if it does. Since all of these write ops use a nested transaction, and there is nothing outstanding in the outer transaction, and the inner transaction has already committed successfully, the only thing that could cause the outer commit to fail would be something like running out of disk for the transaction log.