configuration argument depends on where WiredTiger is installed, not
where the compression library is installed.
Don't try and specify the directory from which configure is being run.
List snappy first, bzip2 is a less likely choice.
Remove mention of the test suite to confirm compression is working.
8. uninit_use: Using uninitialized value "value".
Restructure so we drop core if there's a problem (initialize
key & value to NULL), and we don't read "value" unless it's
been initialized.
Change compaction to attempt compaction any time it looks likely we can
recover the last 10% of the file, and, for now, to only attempt to
recover that last 10% of the file.
Don't rewrite a block if there isn't a useful available block in the
first 90% of the file. (Previously, compacting the whole file in one
pass could end up re-writing blocks to available blocks at the end of
the file which isn't useful, and, in some cases, even extending the
file.
The reason we're only compacting the last 10% of the file is that we
will need to checkpoint periodically otherwise re-written blocks, which
should be the new, available blocks for compaction, won't be considered
because they're still in use. Doing that automatically will be the next
set of changes.
Change compaction to use first-fit allocation instead of best-fit so
we're always copying to the beginning of the file if at all possible.
Add WT_SESSION::create "block_allocation" configuration string, allows
applications to configure first-fit. Change test/format to use the
first-fit algorithm 20% of the time.
Remove the WT_SESSION.compact "trigger" configuration string, it's no
longer used.
Rename WT_SESSION::create "allocation_size" configuration string to
"block_allocation_size" to match "block_allocation" and
"block_compressor" configuration strings.
Inline the block extension search functions, they get called a lot.
Add "compact" verbose debugging string.
Fix a bug where a spinlock could be left held by compaction.
from the statistics_log configuration.
Add error checking, if you specify something like "statistics=(fast,all)",
it should fail.
Write some more statistics documentation.
Now, the database is configured for "none", "fast" or "all" statistics,
and each cursor is configured for "fast" or "all" statistics, with the
additional flag "clear". A cursor's statistics configuration must match
the database statistics cursor, defaulting to the current configuration.
The statistics_log configuration no longer defaults to "fast", it dumps
whatever the database is configured for.
Rename all of the macros from WT_RUNSTAT_XXX to WT_STAT_FAST_XXX.
Reference #715.
success.
Add additional wording that WT_CURSOR::reset should be called after any
of the WT_CURSOR search, search-near, update or remove methods, once
the cursor is no longer being used to iterate or retrieve values.
Closes#587.
the necessary holes to make it work: this change supports checkpoints
of specific target objects (table:foo), but doesn't support generic
database checkpoints (they don't currently fail, but that's because
they don't do anything at all).
Turn off named checkpoints in test/format, when running with the
memrata device.
separate thread because it's possible to copy data out of the cache
without acquiring a lock, so there should be a reasonable amount of
overlap).
Fix a bug in the cache vs. primary comparison code, we were comparing
the value, not the key.
The WT_EXTENSION_API.transaction_oldest method doesn't require a
WT_SESSION handle, simplify it.
Minor re-ordering of the shared library load/unload code to simplify
error handling.
Check if the update can proceed on inserts and updatest, fix the overwrite
stuff (again). Probably still wrong, but I'll wait until I can run the
test suite to fix it.
Add support for setting the transaction state on commit/rollback; walk
the session handle and for every data-source cursor, call an underlying
commit or rollback function. I don't see another solution, so I'm doing
this until Michael weighs in: I'm adding private WT_CURSOR methods the
data-source code sets, which is flatly wrong, but the other approaches
seem worse.
Another WT_EXTENSION_API method: the transaction_snapshot_isolation method
returns if snapshot isolation is configured for the current transaction.
Change the WT_EXTENSION_API transaction_id method to return the transaction
ID; it's no more likely to fail than the other transaction methods, and
I don't see them failing in the future either. It's a little dangerous,
but I'd rather keep error handling simple if we can.
(this version mostly works, supporting the cursor methods other than
search-near).
Add support for two new WT_EXTENSION API methods, collator_config and
collator; the former connects the current sessions collation cookie
to the WT_EXTENSION structure, the second calls it. This is required
for the underlying data-source if it needs to order key/value pairs.
