[Zodb-checkins] CVS: ZODB3 - NEWS.txt:

Tim Peters tim.one at comcast.net
Fri Feb 25 15:31:34 EST 2005

Update of /cvs-repository/ZODB3
In directory cvs.zope.org:/tmp/cvs-serv24962

Modified Files:
      Tag: Zope-2_7-branch
Log Message:
Stop believing the maximum oid cached in a FileStorage's .index file.

This is a critical bugfix, although the problems it addresses are
(a) rare; and, (b) not entirely fixed yet (more checkins to come).

The true max oid is found efficiently now by exploiting the recently-added
fsIndex.maxKey() method (which was, of course, added for this purpose).

Also fix that the .index file could get updated on disk when the
FileStorage was opened in read-only mode.  The code was trying to prevent
this, but missed the most obvious rewrite path.

Incidentally improved many obsolete and/or incorrect comments.

=== ZODB3/NEWS.txt => ===
--- ZODB3/NEWS.txt:	Thu Feb 24 17:41:25 2005
+++ ZODB3/NEWS.txt	Fri Feb 25 15:31:04 2005
@@ -28,6 +28,32 @@
 depending on platform, and should suffer far fewer (if any) intermittent
 "timed out waiting for storage to connect" failures.
+- A FileStorage's index file tried to maintain the index's largest oid as a
+  separate piece of data, incrementally updated over the storage's lifetime.
+  This scheme was more complicated than necessary, so was also more brittle
+  and slower than necessary.  It indirectly participated in a rare but
+  critical bug:  when a FileStorage was created via
+  ``copyTransactionsFrom()``, the "maximum oid" saved in the index file was
+  always 0.  Use that FileStorage, and it could then create "new" oids
+  starting over at 0 again, despite that those oids were already in use by
+  old objects in the database.  Packing a FileStorage has no reason to
+  try to update the maximum oid in the index file either, so this kind of
+  damage could (and did) persist even across packing.
+  The index file's maximum-oid data is ignored now, but is still written
+  out so that ``.index`` files can be read by older versions of ZODB.
+  Finding the true maximum oid is done now by exploiting that the main
+  index is really a kind of BTree (long ago, this wasn't true), and finding
+  the largest key in a BTree is inexpensive.
+- A FileStorage's index file could be updated on disk even if the storage
+  was opened in read-only mode.  That bug has been repaired.
+- An efficient ``maxKey()`` implementation was added to class ``fsIndex``.
 Pickle (in-memory Connection) Cache

More information about the Zodb-checkins mailing list