Berkeley DB 2.7.4 Change Log

Berkeley DB version 2.7.4 is version 2.7.3 with a set of specific bug fixes applied. There were no interface changes or new features.

Bug Fixes:

  1. 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.

  2. 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.

  3. Version 2.7.3 could not recover version 2.4.14 log files.

  4. Database file opens after recovery could sometimes fail.

  5. If only a single checkpoint is found, perform recovery from the beginning of the log.

  6. 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.

  7. Concurrent Data Store operations could sometimes fail because write cursors were not correctly identified.

  8. The DB_SET_RANGE flag did not always correctly deal with on-page deleted records in the Btree access method.

  9. If the buffer cache was completely dirty, transaction checkpoints could pin down too many buffers and cause other operations to fail.

  10. In non-threaded applications, change cursors to share a locker ID in order to avoid self-deadlocks.

  11. In the Btree access method, when creating a new record and specifying a dbt.off offset value, the DB_DBT_PARTIAL flag was not handled correctly.

  12. 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.

  13. Test suite change: generate fail message if environment open doesn't work.

  14. Defend against the possibility that records from multiple log files are present in the log buffer cache.

  15. Reclaim lockers when using lock_vec to release locks.

  16. Re-order subsystem close when closing the environment so that the logging subsystem can potentially flush buffers through the shared memory buffer pool.

  17. Never attempt to grow the shared regions when initially connecting to the Berkeley DB environment.

  18. Invalidate the local transaction structure after commit, abort or prepare, as the XA transaction manager does not call xa_end on commit, abort or prepare.

  19. Allow either join or resume operations on XA start.

  20. Update the version numbers from Berkeley DB 2.7.3 to Berkeley DB 2.7.4.