[SERVER-25969] When featureCompatibilityVersion is 3.2, a 3.4 node can't initial sync decimal data Created: 06/Sep/16 Updated: 19/Nov/16 Resolved: 20/Sep/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.14 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Sprint: | Query 2016-09-19, Query 2016-10-10 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||
| Description |
|
If the primary has featureCompatibilityVersion 3.4, and during initial sync, we copy over decimal data before copying admin.system.version, then we reject the decimal data, and the initial sync fails. We would also like to successfully initial sync from a primary with featureCompatibilityVersion 3.2 that has decimal data, since a user can get into this state by inserting decimal data and then setting featureCompatibilityVersion to 3.2. |
| Comments |
| Comment by Githook User [ 20/Sep/16 ] | |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: This allows secondaries and slaves to sync NumberDecimal even while | |
| Comment by Andy Schwerin [ 06/Sep/16 ] | |
|
That's not good enough. The primary might have decimal data, say, even though it has since had its FCV set to 3.2. The initial sync should not fail because of this. | |
| Comment by Scott Hernandez (Inactive) [ 06/Sep/16 ] | |
|
This seems to be because we start fetching documents (and storing them) before we clone the admin db, to get the upstream setting. Do you have a call-stack from exactly where this happens?
Initial sync does disable other types of validation (like document validation and index constraints) so if there was a way for initial sync to disable this while it executes that would probably be fine. | |
| Comment by Tess Avitabile (Inactive) [ 06/Sep/16 ] | |
|
The secondary validates the incoming BSON. I'm not sure if there is a way to prevent that (or if it is desirable). We could check in rpc/object_check.h whether we are the primary in order to decide which BSON validation version to use, but I'm not sure we'd want to introduce that dependency. If there were a way to construct a Validator<BSONObj> with a particular BSON validation version, we might be able to do that. | |
| Comment by Andy Schwerin [ 06/Sep/16 ] | |
|
Shouldn't we just assume that the upstream node was doing the right thing, and accept whatever data it gives us? |