From the discussion from WT-11845, WiredTiger has uncovered numerous bugs due to the interaction of truncate and other transactions. A large culprit of the reason why truncate is problematic is because there lots of possible cases where transactions could not like how truncate is handling the deletes of a key range. In WiredTiger we have a special functionality within truncate called the fast truncate, which deletes entire contents of pages without the need to read in the page into memory. Slow truncate would instead read back the page into memory and delete each record individually. The important thing to note here is that the behaviour of slow truncate and fast truncate should always result in the exact same behaviour at the end. Which is the correct keys are being deleted.

This ticket aims to uncover any problems that may happen with fast truncate. We can do this by creating a debug configuration to disable the fast truncate path. In doing so, we can mirror a table that does slow truncate only and another table that could enter the fast truncate route. This configuration will be added as a debug configuration and test/format will need to support it. A key few notes to help with the work of this ticket:

• __wt_delete_page is the function where truncate uses decide to delete a page or not.
• READ_TRUNCATE is another flag that used when doing a search to truncate a page.

Either or option can help with disabling the fast truncate operation.