1<!--"$Id: 2.6.6.html,v 1.4 2007/05/17 18:17:18 bostic Exp $ (Sleepycat) $Date: 2007/05/17 18:17:18 $"-->
2<html>
3<head>
4<title>The Berkeley DB Package: DB 2.6.6 Change Log</title>
5<meta name="description" content="Berkeley DB: A database programmatic toolkit.">
6<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods">
7</head>
8<body bgcolor=white>
9
10<h3 align=center>Berkeley DB 2.6.6 Change Log</h3>
11
12<p>
13Berkeley DB version 2.6.6 is version 2.6.5 with all released patches
14applied.
15
16<h3>Bug Fixes:</h3>
17<ol>
18<p><li>
19When looking for an already open log file, do not examine a filename
20structure if its reference count is 0.  This problem cannot cause data
21corruption, but may cause program failure.
22<p><li>
23Berkeley DB recovery assumes that there are at least two checkpoints.  It
24was possible for log archival to leave the recovery area with only a single
25checkpoint.
26<p><li>
27Version 2.6.5 cannot recover version 2.4.14 log files.
28<p><li>
29Database file opens after recovery could sometimes fail.
30<p><li>
31If only a single checkpoint is found, perform recovery from the beginning
32of the log.
33<p><li>
34The Btree access method delete-by-key code path did not always detect that
35a key/data pair was also referenced by a cursor, which could cause a cursor
36to reference incorrect data.
37<p><li>
38Concurrent Data Store operations could sometimes fail because write
39cursors were not correctly identified.
40<p><li>
41The DB_SET_RANGE flag did not always correctly deal with on-page deleted
42records in the Btree access method.
43<p><li>
44If the buffer cache was completely dirty, transaction checkpoints could
45pin down too many buffers and cause other operations to fail.
46<p><li>
47In the Btree access method, when creating a new record and specifying a
48<b>dbt.off</b> offset value, the DB_DBT_PARTIAL flag was not handled
49correctly.
50<p><li>
51It was possible for the last-known-LSN-on-disk to not be set correctly
52during recovery, which could cause the loss of recovery's checkpoint
53record.
54<p><li>
55Reclaim lockers when using lock_vec to release locks.
56<p><li>
57Re-order subsystem close when closing the environment so that the logging
58subsystem can potentially flush buffers through the shared memory buffer
59pool.
60<p><li>
61Never attempt to grow the shared regions when initially connecting to the
62Berkeley DB environment.
63</ol>
64
65<h3>Other Changes:</h3>
66<ol>
67<p><li>
68In non-threaded applications, change cursors to share a locker ID in
69order to avoid self-deadlocks.
70<p><li>
71Defend against the possibility that records from multiple log files are
72present in the log buffer cache.
73<p><li>
74Test suite change: generate fail message if environment open doesn't work.
75<p><li>
76Update the version numbers from Berkeley DB 2.6.5 to Berkeley DB 2.6.6.
77</ol>
78
79</body>
80</html>
81