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?