[SERVER-31241] check compact behavior re: timestamps Created: 25/Sep/17 Updated: 06/Dec/22 Resolved: 29/Sep/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Storage Execution
|
| Participants: |
| Description |
|
compact may or may not erase timestamp data on WiredTiger; we should check the behavior. |
| Comments |
| Comment by Eric Milkie [ 26/Sep/17 ] |
|
No examples, we were just worried that something in the MongoDB code might affect timestamps. It's good to know nothing in the WiredTiger code will affect them. |
| Comment by Alexander Gorrod [ 26/Sep/17 ] |
|
milkie The way compact works in WiredTiger is that it creates new checkpoints in a file using a different block allocation algorithm, and then reclaims unused space at the end of a database file. Since checkpoints can only be created "behind" the stable timestamp the way WiredTiger implements compaction should not overlap with timestamp semantics. Have you seen an example where running compact alters the visibility of data? |