I wanted to see this bsddb3 explosion for myself, so I tried to build the module, but couldn't figure out how to do it. So I opened a bug report under the Build category: [ 775850 ] pybsddb build fails http://sourceforge.net/tracker/index.php?func=detail&aid=775850&group_id=5470&atid=105470 Regards, Zooko
[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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev