Uploaded image for project: 'WiredTiger'
  1. WiredTiger
  2. WT-5631

Recovery rollback to stable for timestamped logged tables

    XMLWordPrintable

    Details

    • Story Points:
      1
    • Sprint:
      Storage Engines 2020-03-09

      Description

      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?

        Attachments

          Activity

            People

            Assignee:
            haribabu.kommi Haribabu Kommi
            Reporter:
            haribabu.kommi Haribabu Kommi
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: