Comment 8 for bug 1595394

On point 4, we need to fix/implement a more robust mechanism to ensure that in the event of a backup/client termination, checkpointing gets re-enabled if the session has disabled it. It's not difficult, it just needs to be done. Backups fail/terminate/abort for many reasons and we need to ensure that we do not compromise the host system as a result of a failure.

On point 5, Ack, I missed this code path in my review, good catch. My point though is still valid. Truncation can only truncate back to the end of the last used block. Because of the way the current block allocator works, the chances of there being blocks allocated at the end of the file is very high. We already are aware that the PerconaFT files do not defragment and shrink themselves correctly in practice. This is of course a different issue but it is a reality that needs to be tested, documented and minimized as much as possible. We have people using TokuDB specifically because of the compression. It then becomes a very difficult argument to make to say they may need up to 2x space if they want to be able to use this solution to perform backups.

I am running some experiments on the side effects of keeping the checkpointer disabled or extended periods of time and will post back my results.