[SERVER-73928] Defer lifetime drop of DeferredDropRecordStore Created: 13/Feb/23 Updated: 16/Feb/23 Resolved: 14/Feb/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jordi Olivares Provencio | Assignee: | Jordi Olivares Provencio |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Sprint: | Execution Team 2023-02-20 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 135 | ||||||||||||||||
| Description |
|
In WT-10576 we found that the way we currently drop temporary collections can lead to invalid memory access. To hit this failure the following must be true:
This is mostly an issue with multi-document transactions but it could be a problem in general. We should either defer the drop until after the commmit/rollback takes place so we don't access invalid memory. |
| Comments |
| Comment by Jordi Olivares Provencio [ 14/Feb/23 ] |
|
Turns out the server already has support for handling EBUSY errors when dropping a collection if WT returns EBUSY when dropping a table. If that's the case, the ident reaper will retry on its next iteration. We've discussed with WT to fix the behaviour of force drops in WT-10576 in order to return EBUSY rather than no error if there's a transaction open on the collection. Closing ticket as Won't Fix since there's nothing to do on the server side. |