[Date Prev][Date Next]
Re: back-bdb deadlocks?
David Boreham wrote:
I note that I posted the back-bdb patch to this list, rather than
committing it to the OpenLDAP CVS, precisely because we cannot impose
such a requirement. It's here for informational purposes until we see
what our friends at Sleepycat have to say.
Ah, I see. I reviewed your e-mail and I don't
think you said that anywhere. I apologize
for not being up to speed on the conventions
of this list wrt proposed changes.
No problem; the point in posting was to get feedback, so it's all for
Indeed. The fact that no access exists to disable
logging on a per-transaction basis suggests that
either a) Sleepycat didn't think it was useful or
b) they knew that it wouldn't work or c) they
didn't want to spend the time determining if it
would work or not. For example, what happens if
you perform a write under one of these no-logging
transactions ? I think bad stuff upon recovery
is possible because the on-disk pages can become
out of sync with the state required to successfully
apply log records. Now, I know that you are not proposing
to perform writes, but if Sleepycat were to implement
your patch I think they'd need to do something extra
to ensure that writes can not be done. Otherwise
there is too much potentential for someone else
using the same feature to shoot their feet off.
There's always plenty of that. The maker of a gun doesn't really have
much control over where the user points it...
re: writes - yes, it's outside the realm of interest here. Such a write
would be non-recoverable *if* the logfile containing it was removed
before it got committed and checkpointed. But that's the same fate as if
the entire environment had logging disabled. If you ask for it, you get
it... If you commit and checkpoint, then there's no problem either way.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support