Berkeley DB 2.3.16 Change Log

Interface Changes Introduced in DB 2.3.16:

  1. The interface to db_jump_set(3) for the DB_FUNC_IOINFO value has changed in order to avoid passing off_t types as interface arguments. Any software that uses this interface must be updated to use the new arguments. See db_internal(3) for more information. This change is NOT transparent to applications.

  2. The output of log_stat(3) has been enhanced to include the current log file number and offset within that file. See db_log(3) for more information.

  3. A new option, -T, has been added to the db_load(1) utility. This option simplifies using non-DB applications (or scripts) to create DB databases. See db_load(1) for more information.

  4. Applications wanting to us the dbm, ndbm or hsearch interfaces to the DB library must now specify a numeric value when they #define DB_DBM_HSEARCH. For example, instead of using:

    #define DB_DBM_HSEARCH
    #include "db.h"

    in the application, they must now use:

    #define DB_DBM_HSEARCH 1
    #include "db.h"

    This change is NOT transparent to applications.

  5. DB no longer intrudes on the historic dbm(3), ndbm(3) or hsearch(3) namespaces. This change permits applications to load the DB library and still load the dbm, ndbm or hsearch functions from another library.

  6. The dbm(3) functions are no longer exported in the Win32 environment. The db_jump_set(3), db_value_set(3) and log_stat(3) interfaces are now exported in the Win32 environment.

  7. In the Java DB API, Dbt's used to retrieve data must specify Db.DB_DBT_MALLOC or Db.DB_DBT_USERMEM in the Dbt flags. If Db.DB_DBT_USERMEM is used, the data field of the Dbt must be set to an appropriately sized byte array.

Bug Fixes:

  2. When transaction undo was performed during recovery, the Btree access method could incorrectly recover pages that were never created because of the system or application failure.

  3. When the last log file did not contain a checkpoint, recovery could potentially fail.

  4. When files were opened and closed between checkpoints, catastrophic recovery could potentially fail.

  5. When log file #2 existed but log file #1 did not, recovery would fail.

  6. Shared memory regions were not being explicitly initialized in the Win95 environment, potentially resulting in unexpected behavior.

  7. An incorrect shared memory region offset was being specified in the shared memory buffer cache support for systems using fcntl(2) locking (rather than spinlock mutexes). This could potentially lead to incorrect locking behavior in that subsystem.

  8. The shared memory buffer cache had a deadlock situation when a buffer writer and a thread or process syncing the pool attempted to write the same buffer at the same time, potentially leading to thread/process starvation.

  9. The Java DB API did not correctly interact with the Db.DB_DBT_MALLOC and Db.DB_DBT_USERMEM flags, and a number of memory leaks have been eliminated.

Additional Changes:

  1. There are a large number of source changes to the DB 2.3.16 release, intended to clean up compiler warnings that could appear when various debugging and warning options were specified to the gcc and Solaris compilers.

  2. DB 2.3.16 has been modified to never pass as arguments or store on disk variables of type off_t. This change is intended to increase DB's portability to compiler/architecture combinations where the DB library and the application may not have been compiled with the same size off_t.

  3. DB now uses the -O2 compiler optimization flag when building on Linux systems.

  4. The shared memory buffer cache subsystem has been enhanced to no longer hold mutex locks across calls to fsync(2).

  5. The shared memory buffer cache subsystem now explicitly yields the processor when waiting on a buffer for which I/O was being performed, enhancing overall throughput.

  6. The test suite has been enhanced to better test recovery and to increase dbm/ndbm interface coverage.