[SERVER-60639] TemporaryRecordStores should destruct by queueing themselves for dropping Created: 12/Oct/21  Updated: 29/Oct/23  Resolved: 25/Oct/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.2.0

Type: Improvement Priority: Major - P3
Reporter: Louis Williams Assignee: Louis Williams
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-59772 Enable setWindowFields in transaction... Closed
is depended on by SERVER-58436 Implement spilling HashAgg Closed
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2021-10-18, Execution Team 2021-11-01
Participants:

 Description   

Our TemporaryRecordStore requires that callers “finalize” by dropping the table (excluding “keeping” it which is used by resumable index builds). The API is a bit clumsy because it requires callers to clean up by dropping the RS, which needs to be done under a Global lock. If this does not happen, the table gets leaked until the next restart.

We can improve this API by allowing the destructor to queue up the drop with the drop-pending ident reaper and a 0 timestamp. This would reap the table immediately in the next pass (every second) and loosens the requirements for the calling operation in addition to making it less likely to leak resources.



 Comments   
Comment by Githook User [ 22/Oct/21 ]

Author:

{'name': 'Louis Williams', 'email': 'louis.williams@mongodb.com', 'username': 'louiswilliams'}

Message: SERVER-60639 Defer TemporaryRecordStore dropping to the storage engine

Users of TemporaryRecordStore no longer have to "finalize" by explicitly dropping the temporary table. Instead, tables are queued in the storage engine to be periodically dropped. All storage engines have the ability to support deferring ident drops.
Branch: master
https://github.com/mongodb/mongo/commit/6d9fecf38c44b0739de5b34c9f82d6a4ed9f508b

Generated at Thu Feb 08 05:50:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.