Access method specific information is provided to db_open using the DB_INFO data argument. The DB_INFO structure has a large number of fields, most specific to a single access method, although a few are shared. The fields that are common to all access methods are listed here; those specific to an individual access method are described below. No reference to the DB_INFO structure is maintained by Berkeley DB, so it is possible to discard it as soon as the db_open call returns.
In order to ensure compatibility with future releases of Berkeley DB, all fields of the DB_INFO structure should be initialized to 0 before the structure is used. Do this by declaring the structure external or static, or by calling the C library function bzero(3) or memset(3).
If possible, defaults appropriate for the system are used for the DB_INFO fields if dbinfo is NULL or any fields of the DB_INFO structure are set to 0. The following DB_INFO fields may be initialized before calling db_open:
Note, the minimum number of pages in the cache should be no less than 10, and the access methods will fail if an insufficiently large cache is specified. In addition, for applications that exhibit strong locality in their data access patterns, increasing the size of the cache can significantly improve application performance.
For information on tuning the Berkeley DB cache size, see
Selecting a cache size.
The value of db_lorder is ignored except when databases are being
created.
If a database already exists, the byte order it uses is determined when
the file is read.
The access methods provide no guarantees about the byte ordering of the
application data stored in the database,
and applications are responsible for maintaining any necessary ordering.
For information on tuning the Berkeley DB page size, see
Selecting a page size.
On systems where there may be multiple library versions of malloc (notably
Windows NT), specifying the DB_DBT_MALLOC flag will fail because
the Berkeley DB library will allocate memory from a different heap than the
application will use to free it.
To avoid this problem, the db_malloc field should be set to
point to the application's allocation routine.
If db_malloc is non-NULL, it will be used to allocate the memory
returned when the DB_DBT_MALLOC flag is set.
The db_malloc function must match the calling conventions of the
malloc(3) library routine.
The following additional fields and flags may be initialized in the DB_INFO structure before calling db_open, when using the Btree access method:
The data and size fields of the DBT are the only fields that may be used for the purposes of this comparison.
If bt_compare is NULL, the keys are compared lexically, with
shorter keys collating before longer keys.
The data and size fields of the DBT are the only fields
that may be used for the purposes of this comparison.
This function is used to compress the keys stored on the btree internal
pages. The usefulness of this is data dependent, but in some data sets
can produce significantly reduced tree sizes and search times.
If bt_prefix is NULL, and no key comparison function
is specified, a default lexical comparison function is used for
prefix compression. If bt_prefix is NULL and a key
comparison function is specified, no prefix compression is done.
It is an error to specify a prefix compression function without
also specifying a key comparison function.
Specifying that duplicates are to be sorted changes the behavior of the
DB->put operation as well as the DBcursor->c_put operation when
the DB_KEYFIRST, DB_KEYLAST and DB_CURRENT
flags are specified.
Logical record numbers in btrees are mutable in the face of record
insertion or deletion.
See the DB_RENUMBER flag in the RECNO section below for further discussion.
Maintaining record counts within a btree introduces a serious point of
contention, namely the page locations where the record counts are stored.
In addition, the entire tree must be locked during both insertions and
deletions, effectively single-threading the tree for those operations.
Specifying DB_RECNUM can result in serious performance degradation for
some applications and data sets.
It is an error to specify both DB_DUP and DB_RECNUM.
The following additional fields and flags may be initialized in the DB_INFO structure before calling db_open, when using the hash access method:
If a hash function is specified, hash_open will attempt to determine
if the hash function specified is the same as the one with which the database
was created, and will fail if it detects that it is not.
Specifying that duplicates are to be sorted changes the behavior of the
DB->put operation as well as the DBcursor->c_put operation when
the DB_KEYFIRST, DB_KEYLAST and DB_CURRENT
flags are specified.
The following additional fields and flags may be initialized in the DB_INFO structure before calling db_open, when using the recno access method:
If the re_source field is non-NULL, it specifies an underlying flat
text database file that is read to initialize a transient record number index.
In the case of variable length records, the records are separated by the byte
value re_delim.
For example, standard UNIX byte stream files can be interpreted as a sequence
of variable length records separated by
In addition, when cached data would normally be written back to the underlying
database file (e.g., the close(2) or sync functions are
called), the in-memory copy of the database will be written back to the
re_source file.
By default, the backing source file is read lazily, i.e., records are not read
from the file until they are requested by the application.
If multiple processes (not threads) are accessing a recno database
concurrently and either inserting or deleting records,
the backing source file must be read in its entirety before more than
a single process accesses the database,
and only that process should specify the backing source file as part
of the db_open call.
See the DB_SNAPSHOT flag below for more information.
Reading and writing the backing source file specified by re_source
cannot be transactionally protected because it involves filesystem
operations that are not part of the Berkeley DB transaction methodology.
For this reason, if a temporary database is used to hold the records,
i.e., a NULL was specified as the file argument to
db_open, it is possible to lose the contents of the
re_source file, e.g., if the system crashes at the right instant.
If a file is used to hold the database, i.e., a file name was specified
as the file argument to db_open, normal database recovery
on that file can be used to prevent information loss, although it is still
possible that the contents of re_source will be lost if the system
crashes.
The re_source file must already exist (but may be zero-length) when
db_open is called.
For all of the above reasons, the re_source field is generally used
to specify databases that are read-only for Berkeley DB applications, and that are
either generated on the fly by software tools, or modified using a different
mechanism, e.g., a text editor.
Any records added to the database that are less than re_len
bytes long are automatically padded.
Any attempt to insert records into the database that are greater than
re_len bytes long will cause the call to fail immediately and
return an error.
Using the DB->put or DBcursor->c_put interfaces to create
new records will cause the creation of multiple records if the record number
is more than one greater than the largest record currently in the database.
For example, creating record 28, when record 25 was previously the last record
in the database, will create records 26 and 27 as well as 28.
Attempts to retrieve records that were created in this manner will result in
an error return of DB_KEYEMPTY.
If a created record is not at the end of the database,
all records following the new record will be automatically renumbered
upward by 1.
For example,
the creation of a new record numbered 8 causes records numbered 8 and
greater to be renumbered upward by 1.
If a cursor was positioned to record number 8 or greater before the insertion,
it will be shifted upward 1 logical record,
continuing to reference the same record as it did before.
For these reasons, concurrent access to a recno database with the DB_RENUMBER
flag specified may be largely meaningless, although it is supported.