[Tim]
>> The evidence suggests there are still potentially catastrophic bugs
>> in bsddb3!
[martin@v.loewis.de]
> So far, I have interpreted all failures in test_bsddb3 as being
> related to the explicit use of transactions. Since the historic bsddb
> module does not provide an interface for transactions, I have always
> concluded that existing code won't be affected by these problems.
I'm guessing we're talking about different things, then. These things have
been discussed recently here:
+ Reports of bsddb3 database corruption in spambayes.
+ Likewise in Richie Hindle's multithreaded test driver, plus
hardware faults.
+ Hangs and AssertionErrors in the tests from
Lib/bsddb/test/test_thread.py.
Richie's program uses only our wrapper's __delitem__, __setitem__ and
__getitem__ implementations. spambayes does the same. While some tests in
test_thread.py use transactions, the AssertionError Skip reported was in a
test that does not use transactions:
http://mail.python.org/pipermail/python-dev/2003-July/036920.html
Fred and Barry also saw the same kind of AssertionErrors in
SimpleThreadBase.writerThread, on the same line. Finally, the hangs Barry
and I saw were in test02_SimpleLocks, which is also devoid of transactions.
So I haven't seen any evidence of problems with transactions -- unless these
things use transactions implicitly in some way.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4