[SERVER-74883] CollectionTruncateMarkers accounts for uninitialized wallTime Created: 15/Mar/23  Updated: 29/Oct/23  Resolved: 12/Apr/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Haley Connelly Assignee: Jordi Olivares Provencio
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2023-04-03, Execution Team 2023-04-17
Participants:

 Description   

There is a condition for CollectionTruncateMarkers that accounts for an uninitialised wallTime. We should investigate whether this is actually possible / should be taken into account. 



 Comments   
Comment by Githook User [ 12/Apr/23 ]

Author:

{'name': 'Jordi Olivares Provencio', 'email': 'jordi.olivares-provencio@mongodb.com', 'username': 'jordiolivares'}

Message: SERVER-74883 Remove wallTime check from truncate markers
Branch: master
https://github.com/mongodb/mongo/commit/9cbd2ec182148cc7cc45ca6351f8310065d1f6f1

Comment by Jordi Olivares Provencio [ 06/Apr/23 ]

Will wait until 7.0 is branched before merging this in to avoid excessive risk

Comment by Jordi Olivares Provencio [ 27/Mar/23 ]

On second thought, this can't be hit even in the previous scenario. At most it would affect startup and the codepath used there takes the "ts" field if the "wall" field doesn't exist.

That is, all entries now have a "wall" field set to the correct value. Will create a PR removing the check.

Comment by Jordi Olivares Provencio [ 24/Mar/23 ]

SERVER-42589 made the wall field required rather than optional in the oplog entries and as of 4.2 the wall time is always reported. The original OplogStones were written much much earlier than 4.2 at a time when the wall time was considered optional.

It's quite possible this is safe to remove, but we might want to consider leaving a comment in CollectionTruncateMarkers explaining the legacy behaviour. I can imagine a scenario where a user upgrading in very rapid succession the cluster, even if it were extremely risky, could hit this. That would be the case with extremely old oplog entries being present that don't have a wall time and haven't yet been truncated.

Generated at Thu Feb 08 06:28:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.