Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited)

[Kim Minh Kaplan]

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