Summary

After the final checkpoint as part of the shutdown command, the metadata table is marked as dirty to let it be checkpointed again as part of the dhandle close to avoid the recovery. But the metadata is never checkpointed as part of the dhandle close due to the WT_CONN_CLOSING_TIMESTAMP flag set before the final checkpoint when the connection close is configured with use_timestamp=true.

            /*             
             * Mark the metadata dirty so we flush it on close, allowing recovery to be skipped.             
             */
            WT_WITH_DHANDLE(s, WT_SESSION_META_DHANDLE(s), __wt_tree_modify_set(s));
 

Motivation

Does this affect any team outside of WT?

NO

How likely is it that this use case or problem will occur?

Recovery performance improvement

If the problem does occur, what are the consequences and how severe are they?

NA

Is this issue urgent?

NA

Acceptance Criteria (Definition of Done)

 Implement the solution described along with the tests.

Testing

Test scenarios where the logging is disabled/enabled, stable timestamp set/unset and shutdown with use_timestamp options.

Documentation update

NA

[Optional] Suggested Solution

With durable history, there is no remaining data that is left out in the tables that need to be discarded. Allow metadata to be checkpointed as part of the shutdown.

Allowing metadata checkpoint on dhandle close can cause problems when the database is configured in the following scenario:

• Open the database with logging disabled
• Set stable timestamp
• close the database with use_timestamp=false

To fix the above problem, mark the metadata dirty only when the logging is enabled. In other scenarios, there is no need to checkpoint metadata again as anyway there is no recovery to be performed.