-
Type: Task
-
Resolution: Done
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
I'm getting EBUSY when attempting to drop a file (via the MongoDB API). The call stack where EBUSY is returned is:
(gdb) where #0 __conn_dhandle_open_lock (session=0x7fffedbe1ba0, dhandle=0x7fffea2cae20, flags=20) at ../src/conn/conn_dhandle.c:68 WT-1 0x00007ffff7b4c1a8 in __conn_dhandle_get (session=0x7fffedbe1ba0, name=0x7fffeee61a40 "file:test.basic1.wt", ckpt=0x0, flags=20) at ../src/conn/conn_dhandle.c:105 WT-2 0x00007ffff7b4ca32 in __wt_conn_btree_get (session=0x7fffedbe1ba0, name=0x7fffeee61a40 "file:test.basic1.wt", ckpt=0x0, op_cfg=0x0, flags=20) at ../src/conn/conn_dhandle.c:387 WT-3 0x00007ffff7ba43a4 in __wt_session_get_btree (session=0x7fffedbe1ba0, uri=0x7fffeee61a40 "file:test.basic1.wt", checkpoint=0x0, cfg=0x0, flags=20) at ../src/session/session_dhandle.c:389 WT-4 0x00007ffff7b4cf09 in __wt_conn_dhandle_close_all (session=0x7fffedbe1ba0, name=0x7fffedc787f0 "file:test.basic1.wt") at ../src/conn/conn_dhandle.c:533 WT-5 0x00007ffff7b95079 in __drop_file (session=0x7fffedbe1ba0, uri=0x7fffedc787f0 "file:test.basic1.wt", force=0, cfg=0x7fffe9298870) at ../src/schema/schema_drop.c:31 WT-6 0x00007ffff7b956c3 in __wt_schema_drop (session=0x7fffedbe1ba0, uri=0x7fffedc787f0 "file:test.basic1.wt", cfg=0x7fffe9298870) at ../src/schema/schema_drop.c:174 WT-7 0x00007ffff7b95460 in __drop_table (session=0x7fffedbe1ba0, uri=0x7fffeef97578 "table:test.basic1", force=0, cfg=0x7fffe9298870) at ../src/schema/schema_drop.c:126 WT-8 0x00007ffff7b957aa in __wt_schema_drop (session=0x7fffedbe1ba0, uri=0x7fffeef97578 "table:test.basic1", cfg=0x7fffe9298870) at ../src/schema/schema_drop.c:180 WT-9 0x00007ffff7ba130a in __session_drop (wt_session=0x7fffedbe1ba0, uri=0x7fffeef97578 "table:test.basic1", config=0x0) at ../src/session/session_api.c:423 WT-10 0x0000000001b11d56 in mongo::WiredTigerDatabaseCatalogEntry::dropCollection ( this=0x7ffff7f336a0, opCtx=0x7fffe929aa60, ns=...)
The write lock fails because there is a read lock still held:
(gdb) p *dhandle->rwlock $57 = {name = 0x7ffff7bb8c09 "data handle", rwlock = {__data = {__lock = 0, __nr_readers = 1, __readers_wakeup = 0, __writer_wakeup = 0, __nr_readers_queued = 0, __nr_writers_queued = 0, __writer = 0, __shared = 0, __pad1 = 0, __pad2 = 0, __flags = 0}, __size = "\000\000\000\000\001", '\000' <repeats 50 times>, __align = 4294967296}}
There are twelve sessions open, none of them have any open cursors.
The code is multi threaded, as far as I'm aware what happens is:
- A session creates the table
- Some items are added to the table, and a query is executed (within the same session that created the file).
- A new session is opened in a different thread
- We call drop from that session handle.
I tried replicating similar steps through the Python API and didn't encounter any failures.
I'll keep digging, but wanted to record a snapshot of the status.
- related to
-
WT-1 placeholder WT-1
- Closed
-
WT-2 What does metadata look like?
- Closed
-
WT-3 What file formats are required?
- Closed
-
WT-4 Flexible cursor traversals
- Closed
-
WT-5 How does pget work: is it necessary?
- Closed
-
WT-6 Complex schema example
- Closed
-
WT-7 Do we need the handle->err/errx methods?
- Closed
-
WT-8 Do we need table load, bulk-load and/or dump methods?
- Closed
-
WT-9 Does adding schema need to be transactional?
- Closed
-
WT-10 Basic "getting started" tutorial
- Closed