Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
WT-2985 checkpoint core dump #3100
that don't have disk addresses in checkpoints is that some of the blocks may have been written, and the checkpoint can leak blocks. We could probably fix it in the block manager layer, but that prevents checkpoints from mapping one-to-one with the blocks in the file, and that's scary.
@keithbostic, sorry for the radio silence -- I've had back to back meetings for several days.
The latest version of this is what I was expecting: checkpoint should visit these pages, I think. That test is intended to skip simple pages that were clean at the beginning of the checkpoint (or on disk) and become dirty while the checkpoint is running. It should not be a common enough case for pages to be this state after a split has failed that there's any measurable performance penalty for visiting them.
@michaelcahill, this last set of changes is passing all of my tests, so if you're happy with it, it's ready to merge.
The reason I resisted the second approach was I don't like the checkpoint sync code looking inside the page modify structure, that's relatively ugly (not that the additional code in reconciliation was all that pretty, but at least it was in reconciliation).
Anyway, the only other idea I had was to add a new "multiblock with failed addresses" flag to the page modify structure, and that's not much better.