[SERVER-42497] Detect/log unintentional untimestamped writes to catalog table Created: 30/Jul/19  Updated: 29/Oct/23  Resolved: 21/Aug/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.3.1

Type: Task Priority: Major - P3
Reporter: Xiangyu Yao (Inactive) Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-42718 dropDatabase commands can be run conc... Closed
depends on SERVER-42834 Adding a namespace to the drop pendin... Closed
depends on SERVER-42830 Applying a rename operation can resul... Closed
Related
is related to SERVER-43018 Formalize contract for safely accessi... Closed
is related to SERVER-44359 Race between oplog visibility thread ... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.2
Sprint: Execution Team 2019-08-12, Execution Team 2019-08-26
Participants:
Linked BF Score: 12

 Description   

SERVER-42185 is a fix for such an untimestamped write in a certain path. However, to prevent such mistakes in the future, we need a way to detect these unintentional untimestamped writes, so that the bug shows up sooner than caught by other checks such as dbhash mismatch which requires a chain of reaction after the untimestamped writes.



 Comments   
Comment by Githook User [ 21/Aug/19 ]

Author:

{'username': 'dgottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'name': 'Daniel Gottlieb'}

Message: SERVER-42497: Detect unintentional untimestamped writes to the durable catalog.
Branch: master
https://github.com/mongodb/mongo/commit/d63202a259f038a8a8ef1af6f67c8cec396de4e5

Comment by Alexander Gorrod [ 21/Aug/19 ]

Woo! Thanks for finding a path forward on this Dan - I'm excited that there is more checking around expected use now.

Comment by Daniel Gottlieb (Inactive) [ 20/Aug/19 ]

Unfortunately assert=(commit_timestamp=always) is not sufficient for the table in question _mdb_catalog:

  1. Some documents in that table are never timestamped, e.g: DDL operations on collections that are not replicated.
  2. Initial syncing will (legally) perform DDL operations without timestamps. I believe successfully altering a table to change it's assertion logic required all WT cursors to be closed (or at least unpositioned).
  3. While it hasn't happened since early integration of timestamping DDL operations, there was a codepath where a timestamp was used for an update which was (illegally) smaller than the timestamp on the previous update.

If we actually do the required server work to make key_consistent viable and there is a notable performance hit, it still might be preferable turning it on in (some/all) testing.

Comment by Susan LoVerso [ 19/Aug/19 ]

The checks for key_consistent are a lot more involved and will likely have a performance impact. The code for always or never is code we're already executing every time we commit (checking if a bit is set).

Comment by Daniel Gottlieb (Inactive) [ 19/Aug/19 ]

Using assert=(commit_timestamp=key_consistent) is still the long-term goal, but that depends on PM-253 being completed.

Comment by Susan LoVerso [ 19/Aug/19 ]

I'm late to this party, but would setting the assert=(commit_timestamp=always) on this table find this for you? (Or durable_timestamp=always if that is a better option.) Setting that should not really have any impact on performance.

Comment by Eric Milkie [ 05/Aug/19 ]

I believe we might only do untimestamped writes to the catalog at startup, so perhaps there's a way to disallow them at other times without a performance hit.

Generated at Thu Feb 08 05:00:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.