[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited)
From: |
Kim Minh Kaplan |
Subject: |
Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited) |
Date: |
Fri, 26 Feb 2010 21:58:17 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
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] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jeff Johnson, 2010/02/24
- Fwd: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jeff Johnson, 2010/02/25
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jeff Johnson, 2010/02/25
- Re: Fwd: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Kim Minh Kaplan, 2010/02/26
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jeff Johnson, 2010/02/26
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited),
Kim Minh Kaplan <=
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jeff Johnson, 2010/02/26
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Kim Minh Kaplan, 2010/02/27
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jeff Johnson, 2010/02/27
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jason Harris, 2010/02/27
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jason Harris, 2010/02/26
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Yaron Minsky, 2010/02/26
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jeff Johnson, 2010/02/26
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jason Harris, 2010/02/27
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Jeff Johnson, 2010/02/27
- Re: [Sks-devel] Adding DB_INIT_LOCK to sks-keyserver (revisited), Marco Nenciarini, 2010/02/27