Michael, what should we do if an application does a bulk-load and then immediately starts doing operations?
The problem is we don't have the root and append pages pinned in memory when bulk load finishes (we set both of them during the open operation, and there's no open operation after a bulk load). So, if you do a bulk load, then an insert, or even a read, we'll go south quickly.
The format program doesn't tickle this because it does a close & re-open after the bulk load phase.
We can either disallow standard operations after bulk-load, or we can futz around underneath the covers to set stuff up.
The reason I brought this up is that it looks like you're doing an internal close-and-reopen step for verify & salvage, maybe there's a clean solution in the API layer?
- is related to
-
WT-75 Bulk-load needs to lock out other cursor operations
- Closed
- related to
-
WT-76 Improve read performance for variable-length column stores
- Closed
-
WT-93 __cursor_set_key allows a recno of 0
- Closed
-
WT-153 add object name to the cursor
- Closed
-
WT-281 Cache resident
- Closed
-
WT-377 Shared cache evict
- Closed
-
WT-410 Update LSM error handling for drop, rename and truncate.
- Closed
-
WT-413 Concurrent checkpoints
- Closed
-
WT-415 Add panic calls to appropriate places in LSM.
- Closed
-
WT-418 Add code in to prioritize eviction of large pages.
- Closed