[SERVER-7720] Building an index with a too-long name should always fail Created: 20/Nov/12 Updated: 12/Jul/17 Resolved: 24/Jun/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 2.2.1 |
| Fix Version/s: | 2.5.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Derek Buttineau | Assignee: | Matt Dannenberg |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Ubuntu Server |
||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Minor Change | ||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
We found (by accident) that if a command that generates an error (in this case a create index that had too long of a name) is shipped to a replica, the replica dies a horrible death. Tue Nov 20 07:48:50 [repl writer worker 2] build index gshiftlabs.blekko_backlink_daily_metrics { presence_id: 1, web_site_id: 1, competitor_id: 1, web_page_id: 1, external_page_id: 1, recorded_on: 1 } background , name: "presence_id_1_web_site_id_1_competitor_id_1_web_page ***aborting after fassert() failure Tue Nov 20 07:48:51 Got signal: 6 (Aborted). Tue Nov 20 07:48:51 Backtrace:
|
| Comments |
| Comment by auto [ 28/May/13 ] |
|
Author: {u'username': u'dannenberg', u'name': u'Matt Dannenberg', u'email': u'matt.dannenberg@10gen.com'}Message: |
| Comment by Derek Buttineau [ 21/Nov/12 ] |
|
In this case, the index was already applied to the primary (but with a supplied shortened name). ensureIndex() was ran again on the primary (but without the name), but since the index already existed on the primary the "too long" error wasn't raised on the primary. The index command was then propagated to the secondaries (which were still recovering so didn't yet have the index) resulting in the error and then the Fatal Assertion. |
| Comment by Daniel Pasette (Inactive) [ 21/Nov/12 ] |
|
What do you mean by "a command that gets shipped to a replica?" If the command errors out on the primary, it should not get propagated to the secondary. |