[SERVER-12349] Insert from update replaces {_id:Timestamp()} with current date+inc Created: 13/Jan/14 Updated: 09/Oct/19 Resolved: 27/Jan/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | 2.5.5 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Craig Wilson | Assignee: | Scott Hernandez (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Major Change | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Steps To Reproduce: |
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
When inserting a document into a collection using a Timestamp as the identifier, if the time and ordinal are both 0, the secondary fails on replication and throws an fassert failure causing mongod to die. In addition, any attempt to restart the secondary will fail as that same op will attempt to replicate and cause the same exception again. This is a change in behavior from the previous 2.4 release line. I tried this with other combinations of timestamps, both in value and in location in the document and it's always when the timestamp is _id with 0's for both of its components.
|
| Comments |
| Comment by Githook User [ 27/Jan/14 ] |
|
Author: {u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}Message: |
| Comment by Scott Hernandez (Inactive) [ 14/Jan/14 ] |
|
Craig, the _id being replaced before was the bug, which is now fixed in insert, but was still broken in update (w/upsert:true -> insert). We have also expanded timestamp replacement to support all top-level fields (except _id). Now the _id field will be immutable and will not do the replacement, and I hope most people would expect. eliot, let me know if this was not the way we wanted to go. Also, I will file another improvement for this state ({_id:Timestamp()}) to be an error since that would catch anyone doing this rather then just silently failing on the first one (since the second one will result in a conflict of Timestamp(0,0) on the unique _id index). Craig, if you have use-cases for using the _id as an expanding unique Timestamp, please file a new issue and we can discuss there and about the use-case(s). |
| Comment by Craig Wilson [ 13/Jan/14 ] |
|
I see the change in the title of the ticket. It's much more explanatory, but it seems backwards. I think the correct statement is that { _id: Timestamp() }is NOT expanded on insert on the primary. This is different behavior than in 2.4. |