[SERVER-8695] different criteria used for determining slaveOk connection in parallel cursor code and Replica set code Created: 25/Feb/13 Updated: 29/Jan/18 Resolved: 01/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Client |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Greg Studer | Assignee: | Dianna Hohensee (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Sharding 2017-03-27, Sharding 2017-08-21 |
| Participants: |
| Description |
|
... the parallel cursor code assumes the slaveOk option is set, while the criteria is now more complex (dbclient_rs.cpp::_isQueryOkToSecondary). If the slaveOk option is set, the parallel cursor assumes it is ok if the primary is unavailable for a version check, since the query may go to an unversioned secondary in any case. However, other queries/commands that go to secondaries are missed in this check. |