[Zope-Checkins] CVS: Zope/doc - CHANGES.txt:1.535.2.100
Wed, 30 Apr 2003 17:21:13 -0400
Update of /cvs-repository/Zope/doc
In directory cvs.zope.org:/tmp/cvs-serv7131
Add all the ZODB bug fixes.
=== Zope/doc/CHANGES.txt 1.535.2.99 => 1.535.2.100 ===
--- Zope/doc/CHANGES.txt:1.535.2.99 Mon Mar 31 12:35:58 2003
+++ Zope/doc/CHANGES.txt Wed Apr 30 17:21:13 2003
@@ -8,6 +8,37 @@
+ - Database invalidations are processed atomically. Each
+ transaction will see all the changes caused by an earlier
+ transaction or none of them. Before this patch, it was
+ possible for a transaction to see invalid data because it saw
+ only a subset of the invalidations. This is the most likely
+ cause of reported BTrees corruption, where keys were stored in
+ the wrong bucket. When a BTree bucket splits, the bucket and
+ the bucket's parent are both modified. If a transaction sees
+ the invalidation for the bucket but not the parent, the BTree
+ in memory will be internally inconsistent and keys can be put
+ in the wrong bucket. The atomic invalidation fix prevents
+ this problem.
+ - Trying to store an object of a non-integer type into an
+ IIBTree or OIBTree could leave the bucket in a variety of
+ insane states. For example, trying
+ b[obj] = "I'm a string, not an integer"
+ where b is an OIBTree. This manifested as a refcount leak in
+ the test suite, but could have been much worse (most likely in
+ real life is that a seemingly arbitrary existing key would "go
+ When deleting the first child of a BTree node with more than
+ one child, a reference to the second child leaked. This could
+ cause the entire bucket chain to leak (not be collected as
+ garbage despite not being referenced anymore).
+ Other minor BTree leak scenarios were also fixed.
- Collector #683: WeDAV request without XML preamble
were not recognized by Zope and raised an exception.
@@ -30,6 +61,24 @@
- Fixed a whitespace problem in Z2.log (AWStats failed to process
+ - It was possible for a transaction that failed in tpc_finish()
+ to lose the traceback that caused the failure. The
+ transaction code was fixed to report the original error as
+ well as any errors that occur while trying to recover from the
+ original error.
+ - Two small bugs were fixed in DemoStorage. undoLog() did not
+ handle its arguments correctly and pack() could accidentally
+ delete objects created in versions.
+ - Fixed trivial bug in fsrecover that prevented it from working at all.
+ - FileStorage will use fsync() on Windows starting with Python 2.2.3.
+ - FileStorage's commit version was fixed. It used to stop after
+ the first object, leaving all the other objects in the