Edit File - File Manager

Edit File: 2.6.6.html

<html>
<head>
<title>The Berkeley DB Package: DB 2.6.6 Change Log</title>
<meta name="description" content="Berkeley DB: A database programmatic toolkit.">
<meta name="keywords" content="embedded,database,programmatic,toolkit,b+tree,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods">
</head>
<body bgcolor=white>

<h3 align=center>Berkeley DB 2.6.6 Change Log</h3>

<p>
Berkeley DB version 2.6.6 is version 2.6.5 with all released patches
applied.

<h3>Bug Fixes:</h3>
<ol>
<p><li>
When looking for an already open log file, do not examine a filename
structure if its reference count is 0.  This problem cannot cause data
corruption, but may cause program failure.
<p><li>
Berkeley DB recovery assumes that there are at least two checkpoints.  It
was possible for log archival to leave the recovery area with only a single
checkpoint.
<p><li>
Version 2.6.5 cannot recover version 2.4.14 log files.
<p><li>
Database file opens after recovery could sometimes fail.
<p><li>
If only a single checkpoint is found, perform recovery from the beginning
of the log.
<p><li>
The Btree access method delete-by-key code path did not always detect that
a key/data pair was also referenced by a cursor, which could cause a cursor
to reference incorrect data.
<p><li>
Concurrent Data Store operations could sometimes fail because write
cursors were not correctly identified.
<p><li>
The DB_SET_RANGE flag did not always correctly deal with on-page deleted
records in the Btree access method.
<p><li>
If the buffer cache was completely dirty, transaction checkpoints could
pin down too many buffers and cause other operations to fail.
<p><li>
In the Btree access method, when creating a new record and specifying a
<b>dbt.off</b> offset value, the DB_DBT_PARTIAL flag was not handled
correctly.
<p><li>
It was possible for the last-known-LSN-on-disk to not be set correctly
during recovery, which could cause the loss of recovery's checkpoint
record.
<p><li>
Reclaim lockers when using lock_vec to release locks.
<p><li>
Re-order subsystem close when closing the environment so that the logging
subsystem can potentially flush buffers through the shared memory buffer
pool.
<p><li>
Never attempt to grow the shared regions when initially connecting to the
Berkeley DB environment.
</ol>

<h3>Other Changes:</h3>
<ol>
<p><li>
In non-threaded applications, change cursors to share a locker ID in
order to avoid self-deadlocks.
<p><li>
Defend against the possibility that records from multiple log files are
present in the log buffer cache.
<p><li>
Test suite change: generate fail message if environment open doesn't work.
<p><li>
Update the version numbers from Berkeley DB 2.6.5 to Berkeley DB 2.6.6.
</ol>

</body>
</html>

Back to File Manager