Re: (ITS#5457) bdb_add() does not always release entries

[hyc@symas.com]

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.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/