With the addition of rollback to stable operation as part of recovery to bring back the checkpoint data to a stable timestamp has some inconsistency behaviours based on the connection open flags.

When the connection flags contain

• Logging enabled - All the timestamped/non-timestamped logged tables have the latest data.
• Logging disabled - All the timestamped logged tables have the data according to the checkpoint stable timestamp and non-timestamped tables have the latest data.

WT decides immediate durability of a table based on the following

• The connection must be enabled for logging or in-memory
• The table is enabled for logging

The problem happens when a connection is opened first with logging enabled and reopened the connection with logging disabled. Due to the conditions in immediate durability, we rollback the timestamped logging tables. eg- test_timestamp10.py. This issue doesn't occur in before durable history, as we never call rollback to stable as part of recovery.

Enabling logging for timestamped tables is not a common scenario. Is it fine to live with current behaviour based on the connection logging behaviour during reopening?