Also, when clearing eviction walk points before the eviction server goes to sleep, clear *all* walks, not just ones that sessions are waiting to be have cleared.
they may be returning something in their own error space we don't want to
overwrite. (We do overwrite the user's error return in the case of a panic,
but I think that's the correct thing to do.)
Rename WT_SESSION_SALVAGE_CORRUPT_OK flag to WT_SESSION_QUIET_CORRUPT_FILE,
it's no longer salvage only.
Set/clear WT_SESSION_QUIET_CORRUPT_FILE around the initial read and verify
of the root page when the file is opened so we don't output scary messages
into the MongoDB log ("item XX on page at YY is a corrupted cell").
Switch to a structure for gcc spinlocks, I couldn't figure out any way
to get alignment for an int. (The structure only has a single field, a
volatile int, so I don't think the code will be any slower).
Remove the typedef on the declaration, it's not needed, the dist scripts
with automatically generate it.
configuration file, which means all subsequent runs (including wt
command runs), inherit the verbose flags from the initial run.
Strip the verbose configuration as part of writing the base
configuration file.
"address", it's really a string identifying where the block came from
(which might be a block-manager address, in printable format), but might
also be something else entirely.
Coverity complains:
CID 1316612 (#1 of 1): Data race condition (MISSING_LOCK)
1. missing_lock: Accessing stats->allocation_size without holding lock
WT_SPINLOCK.lock. Elsewhere, "__wt_dsrc_stats.allocation_size" is
accessed with WT_SPINLOCK.lock held 1 out of 2 times (1 of these
accesses strongly imply that it is necessary).
We're locking around filling in the block manager statistics because
some values are read from the live system which is generally locked.
However, there isn't any reason to lock these reads (they're 8B memory
reads), they're not going to see corruption.
if you don't initialize the random number state, you get 0 as your
random number forever.
I don't think this is a problem because the WiredTiger library always
initializes its random number generation, I noticed because the
mongodb-3.0 branch's test/format code doesn't initialize its random
number generator.
