1<!--"$Id: 2.4.10.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.4.10 Change Log</title> 5<meta name="description" content="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.4.10 Change Log</h3> 11 12<h3>Interface Changes Introduced in DB 2.4.10:</h3> 13<ol> 14 15<p><li> 16Support has been added for architectures with 16-bit integers, largely to 17port Berkeley DB to the Windows 3.1 platform. This required <b>extensive</b> 18code changes, although almost all of them were only semantic in nature. 19In almost all of the DB public interfaces, including any public structure 20elements, all variables of type "int" or "unsigned int" have been converted 21to be either type "int32_t" or "u_int32_t". 22<p> 23Previously built binaries on any 32-bit machine should be backward 24compatible, however, previously built binaries on machines with 64-bit 25integers will not be binarily compatible. Applications should recompile 26correctly without warning or error, unless there are explicit casts in 27the application source code. 28<font color=red> 29This change may NOT be transparent to applications. 30</font> 31 32<p><li> 33Support has been added to allow Berkeley DB to use shared memory backed 34by a paging file or swap space (as opposed to backed by the regular file 35system) on both UNIX and Win95/WNT platforms. This required a major 36rework of the shared memory support in DB, and, for this reason, the DB 37version 2.4.10 release should, perhaps, be tested more thoroughly than 38usual in your local environment before committing to the upgrade. This 39change caused the 40db_jump_set(3) 41and 42db_value_set(3) 43functions to change. 44<p> 45The 46db_jump_set(3) 47function interface specified by the DB_FUNC_MAP flag has changed. 48A new interface, specified by the DB_FUNC_RUNLINK flag has been added. 49Applications replacing these functions at run time will 50require additional care in upgrading to this release of DB. 51<p> 52The 53db_value_set(3) 54function interface has two additional flags: DB_REGION_ANON and 55DB_REGION_NAME, which allow applications to specify regions are 56to be created when using memory backed by a paging file. 57<p> 58See the 59db_internal(3) 60manual page for further information. 61 62<p><li> 63The 64db_jump_set(3) 65interface no longer supports the DB_FUNC_CALLOC and DB_FUNC_STRDUP flags. 66Applications may continue to set the functions associated with those flags, 67but they are no longer needed and no longer have any effect. 68 69<p><li> 70The 71db_value_set(3) 72interface has an additional flag: DB_REGION_INIT, which permits applications 73to specify that regions should be page-faulted into memory immediately upon 74creation. 75This fixes a problem where the additional time required to page-fault in 76region memory caused locks to convoy inside of the shared memory buffer pool. 77<p> 78This additionally required an interface change to the DB_FUNC_SEEK interface 79as specified by the 80db_jump_set(3) 81function interface. 82The "relative" argument is now a "u_int32_t" instead of a "u_long", 83and there is an additional argument "isrewind" in order to support 84seeking in the reverse direction. 85<p> 86See the 87db_internal(3) 88manual page for further information. 89<font color=red> 90This change may NOT be transparent to applications. 91</font> 92 93<p><li> 94The 95log_put(3) 96function has an additional flag: DB_CURLSN, which permits applications 97to determine the next log LSN value which will be used. 98This, coupled with changes to the transaction subsystem to no longer 99write transaction-begin records allows Berkeley DB to avoid writing 100any log records in the case of read-only transactions. 101 102<p><li> 103The interface to the 104hcreate(3) 105function has been changed to take a "size_t" as an argument instead of 106an "unsigned int", for compatibility with vendor platforms, notably Solaris. 107<font color=red> 108This change may NOT be transparent to applications. 109</font> 110 111<p><li> 112Specifying NULL or zero-length keys to DB functions is now explicitly 113disallowed by most of the DB interfaces, and EINVAL will be returned. 114<font color=red> 115This change may NOT be transparent to applications. 116</font> 117 118<p><li> 119Performance measurements of Berkeley DB indicated that a significant 120amount of time was being spent clearing pages created in the shared 121memory buffer pool. 122In order to fix this, additional information has been added to the 123memp_fopen(3) 124interface which allows callers to specify the number of bytes which 125need to be cleared when pages are created in the pool. 126The default behavior of the pool code is unchanged, and by default the 127entire page is cleared. 128<p> 129However, the 130memp_fopen(3) 131function interface has changed: 4 of the lesser-used historic arguments 132and the new argument have been moved to an information structure of type 133DB_MPOOL_FINFO which is passed to the memp_fget function as an argument. 134See the 135db_mpool(3) 136man page for more information. 137<font color=red> 138This change may NOT be transparent to applications. 139</font> 140 141<p><li> 142An interface has been added to the 143db_checkpoint(1) 144function allowing database administrators to force a single checkpoint. 145See the 146db_checkpoint(1) 147man page for more information. 148 149</ol> 150 151<h3>Configuration and Build Changes:</h3> 152 153<ol> 154 155<p><li> 156The environment variables used to specify a compiler, loader or compile 157and loader flags during DB configuration have been changed to be more in 158line with standard GNU autoconf practice. The changes are as follows: 159<p> 160<table border> 161<tr><td>Old Name</td><td>New Name</td></tr> 162<tr><td>ADDCPPFLAGS</td><td>CPPFLAGS</td></tr> 163<tr><td>ADDCXXFLAGS</td><td>CXXFLAGS</td></tr> 164<tr><td>ADDLDFLAGS</td><td>LDFLAGS</td></tr> 165<tr><td>ADDLIBS</td><td>LIBS</td></tr> 166</table> 167<p> 168See the file build.unix/README for further information. 169 170<p><li> 171The DB debugging support (previously configured by specifying 172<b>--enable-debug</b> during configuration) has been split into two 173separate pieces of functionality. 174<p> 175To build DB with -g as a compiler flag and with DEBUG #defined during 176compilation, enter <b>--enable-debug</b> as an argument to configure. 177This will create DB with debugging symbols, as well as load various 178routines that can be called from a debugger to display pages, cursor 179queues and so forth. This flag should probably not be specified when 180configuring to build production binaries, although there shouldn't be 181any significant performance degradation. 182<p> 183To build DB with diagnostic, run-time sanity checks and with DIAGNOSTIC 184#defined during compilation, enter <b>--enable-diagnostic</b> as an 185argument to configure. This will cause a number of special checks to be 186performed when DB is running. This flag should <b>NOT</b> be specified 187when configuring to build production binaries, as you will lose a 188significant amount of performance. 189 190<p><li> 191Some systems, notably versions of AIX, HP/UX and Solaris, require 192special compile-time options in order to create files larger than 1932^32 bytes. These options are automatically enabled when DB is 194compiled. For this reason, binaries built on current versions of 195these systems may not run on earlier versions of the system, as 196the library and system calls necessary for large files are not 197available. To disable building with these compile-time options, 198enter <b>--disable-bigfile</b>. 199 200<p><li> 201The autoconf configure script has been enhanced to correctly support 202<b>--disable-feature</b> or <b>--enable-feature=no</b> options. 203 204<p><li> 205The Berkeley DB test suite has been re-ordered to run system tests before 206the tests of the individual access methods. 207 208<p><li> 209The Berkeley DB test suite has been largely ported to the Windows 3.1 210environment. See the distribution file test/README.win32 for more 211information. 212 213<p><li> 214Mutex lock support for the GCC compiler and the PaRisc architecture has 215been added. 216 217<p><li> 218The db_printlog(1) debugging utility is now built by default, 219and the 220db_stat(1) 221utility is now built on Win95/WNT platforms. 222 223<p><li> 224A number of C, C++ and Java compiler warnings have been fixed. 225 226<p><li> 227Support has been added for the Siemens-Nixdorf Informationssysteme AG 228ReliantUNIX platform. 229 230<p><li> 231Ports of Berkeley DB to the HP MPE/iX and Windows 3.1 environments have 232been begun. They are not yet complete. 233 234</ol> 235 236<h3>B+tree Access Method Bug Fixes:</h3> 237 238<ol> 239 240<p><li> 241When performing btree range searches (that is, using the DB_SET_RANGE 242interface, or using the DB version 1.85 compatibility interface), the 243Btree access method could incorrectly return already deleted records. 244 245<p><li> 246When using a cursor to delete key/data pairs from a btree database, it 247was possible to leave empty pages in the database. This did not cause 248incorrect behavior, however, it could lead to unexpected growth in the 249database. 250 251<p><li> 252When doing a partial put into a off-page (that is, "overflow") record, 253the Btree access method could incorrectly store the data item. 254 255<p><li> 256When an off-page (that is, "overflow") record was promoted to an internal 257page of a Btree database, DB applications could dump core when walking 258the tree on machines where a certain stack variable was not automatically 259initialized to 0. 260 261<p><li> 262When an off-page (that is, "overflow") item was promoted into an internal 263page in a Btree database, DB applications reading databases on machines 264with different byte orders could incorrectly walk the Btree, potentially 265dumping core. 266 267<p><li> 268When Btree databases had record numbering turned on (the DB_RECNUM 269option), it was possible for the record numbers to fail to stay 270synchronized with changes in the database. 271 272</ol> 273 274<h3>Recno Access Method Bug Fixes:</h3> 275 276<ol> 277 278<p><li> 279When iterating through Recno access method databases, DB could incorrectly 280return EINVAL instead of the next key/data pair. 281 282<p><li> 283Previous releases of DB did not permit Recno access method databases to 284be opened read-only. 285 286<p><li> 287When reading the last record in a Recno access method database, DB could 288incorrectly return DB_NOTFOUND instead of the key/data pair. 289 290<p><li> 291When a key/data item was deleted using the cursor interface to a Recno 292access method database, a subsequent put using DB_NOOVERWRITE set would 293fail. 294 295<p><li> 296Because DB version 2 lazily instantiates the underlying shared memory 297buffer pool files, the DB->fd call for Recno databases in the DB 1.85 298compatibility interface did not always work. 299 300</ol> 301 302<h3>C++ and Java API Bug Fixes:</h3> 303 304<ol> 305 306<p><li> 307When the C++ interface 308Db::get() 309function was called, DB incorrectly treated the DB_NOTFOUND case as an 310exception instead of returning DB_NOTFOUND. 311 312<p><li> 313The DB Java interface now sets the CLASSPATH variable instead of depending 314on -classpath. This allows DB to work with the SGI JDK 3.0.1. 315 316<p><li> 317Using Dbc.next with the DB_SET or DB_SET_RANGE options in the DB Java 318interface would not correctly position the cursor. 319 320<p><li> 321The DB Java interface now works correctly with the Solaris JDK 1.2. 322 323</ol> 324 325<h3>Additional Bug Fixes:</h3> 326 327<ol> 328 329<p><li> 330Shared regions now work correctly for multiple processes on Windows/95 331platforms. 332 333<p><li> 334It was possible under rare conditions to return illegal addresses when 335read-only databases were mapped into the process address space. 336 337<p><li> 338When a DB environment had already been specified, setting the 339"db_cachesize" field of the DB_INFO structure would be silently 340ignored by 341db_open(3). 342In DB version 2.4.10, specifying a DB environment as well as setting 343db_cachesize is considered an error, returning EINVAL. 344 345<p><li> 346Several boundary conditions were identified and fixed in database 347recovery. 348 349<p><li> 350Key-not-found and errno returns were being set incorrectly in the 351dbm/ndbm interface compatibility functions. 352 353<p><li> 354Under some conditions, database files could still be synced to disk on 355close, even if the DB_NOSYNC flag was specified to the DB->close function. 356 357<p><li> 358Under some conditions, the db_archive utility output could contain 359multiple slashes in pathnames. 360 361<p><li> 362The db_archive utility would always prepend the current working 363directory pathname when the -a option was specified, regardless 364of the DB environment information indicating that the database 365home was at an absolute pathname. 366 367<p><li> 368Page create statistics were not correctly maintained when the 369DB_MPOOL_NEW option was specified to the shared memory buffer 370pool subsystem. 371 372<p><li> 373Under rare conditions, log offsets were not maintained correctly when 374switching between log files. 375 376</ol> 377 378<h3>Additional Changes:</h3> 379 380<ol> 381 382<p><li> 383The transaction ID space in Berkeley DB is 2<sup>31</sup>, or 2 billion 384entries. 385It is possible that some environments may need to be aware of this limitation. 386Consider an application performing 600 transactions a second for 15 hours a 387day. 388The transaction ID space will run out in roughly 66 days: 389<blockquote> 3902<sup>31</sup> / (600 * 15 * 60 * 60) = 66 391</blockquote> 392<p> 393Doing only 100 transactions a second exhausts the transaction ID space in 394roughly one year. 395<p> 396In order to decrease the likelihood of exhausting the transaction ID space, 397Berkeley DB now resets the transaction ID each time that recovery is run. 398See 399db_txn(1) 400for more information. 401 402<p><li> 403The limitations on database lifetime imposed by the Berkeley DB logging 404subsystem has been documented. See 405db_log(3) 406for more information. 407 408<p><li> 409Performance measurements of Berkeley DB indicated that a significant 410amount of time was spent in searching hash queues in the shared memory 411buffer pools. The internal DB hash bucket code has been enhanced to 412handle much larger core memories than was possible previously, which 413should result in increased performance when using large memory pool 414caches. 415 416<p><li> 417Performance measurements of Berkeley DB indicated that a significant 418amount of time was spent in searching lock queues, and, specifically, in 419calculating hash values of lock queue elements. Fast hash functions 420specifically for DB's use have been added to the lock subsystem to 421alleviate this problem. 422 423<p><li> 424Performance measurements of Berkeley DB indicated that a significant 425amount of time was spent in determining the number of processors on 426the Windows/NT platform. The value is now determined initially and 427then stored. 428 429<p><li> 430Historically, the 431db_appinit(3) 432function returned EINVAL if an application attempted recovery, by 433specifying DB_RECOVER or DB_RECOVER_FATAL, and there were no log 434files currently in the database environment. In the 2.4.10 release, 435this is no longer an error. 436 437<p><li> 438The mutex locking code has been enhanced to no longer attempt full 439test-and-set instructions unless there is a strong probability of 440acquiring the mutex. This makes spinning on the mutex significantly 441less expensive. 442 443<p><li> 444The count of attempted mutex locks (mutex_set_wait) has been changed to 445be incremented every time a process/thread is refused the lock, instead 446of only once when it first requests the lock and is denied. 447 448<p><li> 449The 450db_dump185(1) 451utility has been enhanced to dump DB version 1.86 databases as well as 452DB version 1.85 databases. 453 454<p><li> 455The 456db_stat(1) 457utility has been enhanced to display values larger than 10 million in 458a new format, "###M". 459 460<p><li> 461The 462db_stat(1) 463utility has been enhanced to display lock region statistics. 464See 465db_stat(1) 466and 467db_lock(3) 468for more information. 469 470</ol> 471 472</body> 473</html> 474