[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:
Depends
Related
is related to SERVER-74085 Ensure queries that spill to Temporar... Backlog
is related to WT-10576 Return EBUSY on forced drop if there ... In Code Review
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:

  • Operation A has a WT transaction open and has modified collection C
  • Collection C is dropped
  • Operation A performs a commit/rollback

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.

Generated at Thu Feb 08 06:26:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.