Summary

Rollback to stable (RTS) must be extended to identify and roll back prepared fast truncate operations. Currently, RTS handles prepared updates on individual keys but does not account for prepared WT_PAGE_DELETED records representing whole-page truncations. These must be rolled back when the stable timestamp requires it.

Motivation

RTS is responsible for removing any transaction state that is not stable — including prepared transactions that were never committed. Fast truncate is a prepared write that covers an entire page rather than individual keys. If RTS does not roll back prepared fast truncate records, pages that should be visible after rollback will remain incorrectly marked as deleted, causing data loss or incorrect query results.

Acceptance Criteria

• RTS identifies WT_PAGE_DELETED records belonging to prepared transactions whose prepare timestamp is after the stable timestamp
• RTS correctly rolls back such prepared fast truncate records, restoring page visibility
• The rollback path handles both in-memory and on-disk (recovered) prepared fast truncate state
• Existing RTS and fast truncate tests pass with no regression