[SERVER-20529] WiredTiger allows capped collection objects to grow Created: 21/Sep/15 Updated: 10/Jan/22 Resolved: 09/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage, WiredTiger |
| Affects Version/s: | 3.0.2 |
| Fix Version/s: | 3.2.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | John Page | Assignee: | Geert Bosch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||
| Sprint: | QuInt A (10/12/15) | ||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||
| Description |
|
In MMAP items in a capped collection cannot grow - as per the documentation and an error is raised if they do.
In WiredTiger they are allowed to grow - is this deliberate?
|
| Comments |
| Comment by Akira Kurogane [ 27/Dec/17 ] |
|
Just for web-search reasons: The message this patch added to logging is "10003 Cannot change the size of a document in a capped collection" |
| Comment by Githook User [ 09/Oct/15 ] |
|
Author: {u'username': u'GeertBosch', u'name': u'Geert Bosch', u'email': u'geert@mongodb.com'}Message: |
| Comment by Daniel Pasette (Inactive) [ 30/Sep/15 ] |
|
For the reasons Geert gave, we need to allow updates which don't change the document size. However, I think we should restrict all storage engines to allow only updates which don't change the document size in capped collections. I don't think we want other storage engines to have to have the concept of a "Record" which wraps the document as we do in MMAPv1. This is a backward breaking change. Does anyone know of any legitimate use cases which this would break? |
| Comment by Geert Bosch [ 29/Sep/15 ] |
|
By far the easiest and would be to uniformly disallow all updates that result in size changes. The reason we should probably still allow some updates that do not result in size changes is that these are sometimes used to fixup logOp entries, which is considered an important capability by our support team. Allowing records to shrink is not very good, as such an update cannot be undone (because that would result in growth), or we'd have to pad shrunk records, which is really a concept I'd like to avoid outside of MMAPv1. |
| Comment by David Hows [ 28/Sep/15 ] |
|
Looking through the update code, as of 3.1.8 ( To me, Asya's suggestion around blocking all updates to capped collections seems the best direction to pursue as she is spot on about potential replication issues for any update to a capped collection and it would seem unwise to insist that each storage engine should perform this check at insert time. Does anyone know of cases where we currently need to update a capped collection internally? I couldn't think of any, can anyone else? Does MMS rely on doing updates (including non-growth updates) internally? The only suggested reason in |
| Comment by Asya Kamsky [ 21/Sep/15 ] |
|
Capped collection updates cannot be allowed regardless of storage engine since WT primary may be replicating to MMAPV1 secondary and the update would fail on the secondary. |