WT-2897 Checkpoints can become corrupted on failure (#3027)

During a checkpoint, the extent lists of previous checkpoints that are being
discarded are merged into the live system's extent lists. If there's an error
(most likely disk-full causing a write to fail), the live system's allocation
list can be left corrupted. Future checkpoints are not locked out by this
failure, which means a subsequent checkpoint (for example, the sweep server
closing the file) could potentially create a checkpoint based on corrupted
extent lists.

After the live system's extent lists have been modified during a checkpoint,
change errors to switch the handle into read-only mode and panic the system.

Second, the checks for re-entering the checkpoint code don't prevent bugs in
the upper-level code from affecting checkpoints, and I'm suspicious that is
happening. Adjust the in-checkpoint tests and use the live system's lock to
ensure the checkpoint code is never re-entered.

0 files changed, 0 insertions, 0 deletions