[Date Prev][Date Next] [Chronological] [Thread] [Top]

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 the good.

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
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support