1<!--"$Id: 2.4.14.html,v 1.3 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.14 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.14 Change Log</h3> 11 12<h3>Interface Changes Introduced in DB 2.4.14:</h3> 13<ol> 14 15<p><li> 16Enhance the 17db_load(1) 18utility so that the default behavior is to add data to existing databases 19(rather than to always create the database), and to correctly perform 20locking for databases running in Berkeley DB environments. This allows 21the use of 22db_load(1) 23to add key/data pairs to existing, active databases. 24<p> 25Add a <b>-n</b> option to the 26db_load(1) 27This option causes 28db_load(1) 29to refuse to overwrite already existing key/data pairs in databases. 30 31<p><li> 32Enhance the 33db_stat(1) 34utility to display additional information about the shared memory buffer 35pool and lock regions. The new options are <b>-C[Acflmo]</b> for the 36lock region, and <b>-M[Ahlm]</b> for the shared memory buffer pool region. 37This information is normally intended only for Berkeley DB performance 38tuning. 39 40<p> 41Add a <b>-N</b> option to the 42db_stat(1) 43This option keeps 44db_stat(1) 45from acquiring region locks when reading shared regions, which allows 46db_stat(1) 47to be used to display information about regions where applications have 48crashed while holding region locks. 49 50<p> 51Add region reference counts and sizes to all 52db_stat(1) 53region displays. 54 55<p><li> 56Add a new flag, <b>DB_MUTEXLOCKS</b> to the 57db_value_set(1) 58interface. This flag causes requests for mutual exclusion mutexes to 59be immediately granted without test. This flag is only intended for 60debugging purposes. 61 62</ol> 63<h3>B+tree Access Method Bug Fixes:</h3> 64<ol> 65 66<p><li> 67Fix bug in the B+tree access method where additional cursors could be 68incorrectly updated when key/data pairs were added or deleted. 69 70<p><li> 71Fix bug where an aborted transaction during a B+tree split could cause 72pages to be left pinned. 73 74<p><li> 75Fix possible core dump when freeing the (cursor referenced) last item 76in the last page in a duplicate chain. 77 78<p><li> 79Fix possible core dump when deleting overflow items from duplicate pages. 80 81<p><li> 82Fix bug where duplicate page splits could result in database corruption 83(common to both B+tree and Hash Access Methods). 84 85</ol> 86<h3>Hash Access Method Bug Fixes:</h3> 87<ol> 88 89<p><li> 90Fix bug where Hash access method recovery did not always correctly recover 91key/data pair addition or deletion. 92 93<p><li> 94Fix bug where deleting a key in a Hash access method database could cause 95a cursor sequentially walking the database to skip records. 96 97<p><li> 98Fix bug where duplicate page splits could result in database corruption 99(common to both B+tree and Hash Access Methods). 100 101</ol> 102<h3>Shared Memory Buffer Pool Bug Fixes:</h3> 103<ol> 104 105<p><li> 106Fix bug where a DB thread handle could be left locked if a read-only file 107descriptor could not be upgraded to read-write during a buffer pool sync 108to disk. 109 110</ol> 111<h3>Common Shared Region Support Bug Fixes:</h3> 112<ol> 113 114<p><li> 115Fix bug where private shared memory pool regions could not be created on 116architectures without spinlock mutex support. 117 118<p><li> 119Fix possible file descriptor leak on HP/UX architecture (reports #150, 120#158). 121 122<p><li> 123Fix a variety of inconsistencies where, after a failed attempt to open 124shared regions, the code recovery paths were incorrect. 125 126</ol> 127<h3>Additional Bug Fixes:</h3> 128<ol> 129 130<p><li> 131Fix possible core dump in 132lock_open(1) 133when it was called without first creating a Berkeley DB database environment. 134 135</ol> 136<h3>Test Suite, Example Program and Build Procedure Bug Fixes and Changes:</h3> 137<ol> 138 139<p><li> 140Fix build procedures for a number of architectures: affected systems 141include VC++ 5.0 and various releases of SunOS, AIX, OSF/1, FreeBSD 142and Linux (reports #145, #156). 143 144<p><li> 145Fix the Berkeley DB test suite to correctly identify Windows systems 146in all cases (the previous method failed for some releases of the 147Tcl scripting language). 148 149<p><li> 150Fix the <b>ex_thread</b> example program to correctly set the buffer 151cache size. 152 153<p><li> 154Fix the Berkeley DB test suite to ignore errors where System V shared 155memory interfaces (shmget(2)) have not been configured correctly. 156 157<p><li> 158Add support for the BSD/OS 4.0 release. 159 160<p><li> 161Add support for the SCO OpenServer Release 5 (3.2.2). (The test suite 162has not yet run successfully on this architecture, although we currently 163believe that the problems are in the test suite, and not in the Berkeley 164DB library itself.) 165 166<p><li> 167Change configuration to ignore the FreeBSD shmget(2) interfaces when 168ftok(3) is not available from the C library. 169 170<p><li> 171Change configuration to fail on the Nextstep architecture. (Previously, 172Berkeley DB would configure successfully, but then not build on Nextstep.) 173 174</ol> 175<h3>Additional Changes:</h3> 176<ol> 177 178<p><li> 179Return EINVAL if the DB_RECOVER or DB_RECOVER_FATAL flags were specified to 180db_appinit(3) without also specifying the DB_INIT_TXN flag. 181 182<p><li> 183Removed "Additional Change" #7 from the Berkeley DB 2.4.10 release: 184<p> 185<blockquote> 186The mutex locking code has been enhanced to no longer attempt full 187test-and-set instructions unless there is a strong probability of 188acquiring the mutex. This makes spinning on the mutex significantly 189less expensive. 190</blockquote> 191<p> 192Full test-and-set instructions are necessary on some architectures, and 193it this change actually decreased performance in some cases. 194 195</ol> 196 197</body> 198</html> 199