- 
    Type:Bug 
- 
    Resolution: Fixed
- 
    Priority:Major - P3 
- 
    Affects Version/s: 5.3.0, 5.0.0, 6.0.0, 7.0.0, 7.2.0-rc0
- 
    Component/s: None
- 
    None
- 
        Query Optimization
- 
        Fully Compatible
- 
        ALL
- 
        v7.2, v7.0, v6.0, v5.0
- 
        QO 2023-12-11, QO 2023-12-25, QO 2024-01-08, QO 2024-01-22
- 
        145
- 
        None
- 
        None
- 
        None
- 
        None
- 
        None
- 
        None
- 
        None
On a clustered collection when notablescan is enabled:
- Query to delete multiple documents using a secondary index on the primary. Eg., db.coll.remove({x:{$gte:0}}), where an index is defined for the field x.
- We replicate oplog entries to delete documents on the secondary replica by _id
- On the secondary, the deletion is not done by the indexed field x but by _id. However, the query system doesn't recognize the clustered index as a real _id index, and it fails. This causes a crash of the secondary replica.
In this scenario, the plan for the delete by _id on the secondary would include a CLUSTERED_IXSCAN and thus should not be blocked by the notablescan setting.
The solution is to fix the planner logic to allow CLUSTERED_IXSCAN with the notablescan setting.
See the repro script in the comment below and see the code here
- is related to
- 
                    SERVER-83475 Passthrough tests for notablescan -         
- Closed
 
-