I am a...
I want to...
Berkeley DB 2.7.4 Change Log
When looking for an already open log file, do not examine a file name structure if its reference count is 0. This problem cannot cause data corruption, but may cause program failure.
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.
Version 2.7.3 could not recover version 2.4.14 log files.
Database file opens after recovery could sometimes fail.
If only a single checkpoint is found, perform recovery from the beginning of the log.
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.
Concurrent Data Store operations could sometimes fail because write cursors were not correctly identified.
The DB_SET_RANGE flag did not always correctly deal with on-page deleted records in the Btree access method.
If the buffer cache was completely dirty, transaction checkpoints could pin down too many buffers and cause other operations to fail.
In non-threaded applications, change cursors to share a locker ID in order to avoid self-deadlocks.
In the Btree access method, when creating a new record and specifying a
offset value, the DB_DBT_PARTIAL flag was not handled correctly.
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.
Test suite change: generate fail message if environment open doesn't work.
Defend against the possibility that records from multiple log files are present in the log buffer cache.
Reclaim lockers when using lock_vec to release locks.
Re-order subsystem close when closing the environment so that the logging subsystem can potentially flush buffers through the shared memory buffer pool.
Never attempt to grow the shared regions when initially connecting to the Berkeley DB environment.
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.
Allow either join or resume operations on XA start.
Update the version numbers from Berkeley DB 2.7.3 to Berkeley DB 2.7.4.
E-mail this page
Learn About Oracle Cloud Computing
Get a Free Trial
Learn About DaaS
Learn About SaaS
Learn About PaaS
Learn About IaaS
Learn About Private Cloud
Learn About Managed Cloud
Learn About Java
Download Java for Consumers
Download Java for Developers
Java Resources for Developers
Java Cloud Service
Customers and Events
Explore and Read Customer Stories
All Oracle Events
Social Media Channels
Services and Store
Log In to My Oracle Support
Training and Certification
Become a Partner
Find a Partner Solution
Purchase from the Oracle Store
Contact and Chat
Hardware and Software, Engineered to Work Together
Oracle RSS Feed