[SERVER-36953] afterClusterTime reads should not block on prepare conflicts if their afterClusterTime is before the oldest prepare timestamp Created: 30/Aug/18  Updated: 06/Dec/22  Resolved: 17/May/19

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

Type: Improvement Priority: Major - P3
Reporter: Samyukta Lanka Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: open_todo_in_code, prepare_optional, todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-36382 only snapshot, linearizable, and afte... Closed
Related
related to SERVER-42544 Complete TODO listed in SERVER-36953 Closed
Assigned Teams:
Replication
Participants:

 Description   

After SERVER-36382, all afterClusterTime reads block on prepare conflicts.



 Comments   
Comment by Gregory McKeon (Inactive) [ 17/May/19 ]

We could do this optimization in the future more fully, but not this way and not now.

Comment by Samyukta Lanka [ 07/Sep/18 ]

This ticket is really only a concern for local reads with an afterClusterTime because those reads aren't timestamped. We'd like to investigate if it's worth timestamping local reads on the primary (they are currently timestamped on the secondary) or if we should just do the solution offered in this ticket.

We determined that this is optional work and not a priority right now, so I'm setting the ticket back to Open and putting it on the backlog.

Generated at Thu Feb 08 04:44:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.