[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: |
|
||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
After |
| 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. |