Jeff Johnson writes: > From the 3 deadlocks I've seen, I'd guess that any moderately large > (>500 keys) is likely to encounter a partition tree deadlock if > DB_INIT_LOCK is enabled. > > (untried, will test) Rebuilding the partition tree might also > reproduce. OTOH, that might be a different code path, I'm still > sorting out the implementation.
Just to try it out, I uncommented the Dbenv.INIT_LOCK from pTreeDB.ml and built the prefix tree for a 75,000 key database but could not produce a deadlock. > Meanwhile, db_recover is only as good as the logs that are present, > often only back to the last hourly checkpoint. If logs are being > automatically removed, damage to data in the secondary indices earlier > than the last checkpoint cannot be repaired without db_dump/db_load > afaict. This is not my understanding of the phrase "All committed transactions are guaranteed to appear after db_recover has run, and all uncommitted transactions will be completely undone"[1]. As I understand it, after a db_recover the database should contain *everything* that has been committed. Regarding automatic removal of log files, I hope you are refering to "log files that are no longer in use"[2] in which case they are not needed for normal db_recover operation (i.e. to recover from a crash of SKS). They are only needed when catastrophic failure occur but I do not think this what we are talking about. > If the secondary indices get out of sync with the primary key store, there's > a class of lookup failure "weirdness" that force recreating the key database > from a dump. > > With DB->associate SKS does not use secondary indices in the sense of DB->associate. [1] http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/C/db_recover.html [2] http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/C/db_archive.html -- Kim Minh _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/sks-devel
