-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Schema Management
-
None
-
Storage Engines - Foundations
-
SE Foundations - Q4+ Backlog
-
3
I noticed a potential problem when performing session->drop(). Here is the scenario:
- A cursor is opened on the ingest table, and none on the stable table
- Call Drop() on the layered table. The drop functionality will remove the stable table and then return EBUSY on the ingest table because of pinned cursor.
- An EBUSY error is returned from session->drop(), leaving the layered table in an inconsistent state.
From the user perspective, the table should be in a correct state when an EBUSY is returned.