With the current plan, if we make updates to history store, the updates are done as part of the application transaction (which means we need one of this txns open in the first place). For this plan to work, we need to put a hack into the commit/rollback code to always treat history store updates as committed.
It will be effective to find alternatives to the above mechanism for two reasons:
- We won't have to do the mentioned hack and treat history store updates special
- We wont have to open a transaction if application txn is not available. We do not want to open a txn just to make history store updates because history store updates do not follow regular transaction semantics also this might interfere with implicit auto transactions that an application might end up opening.
- is depended on by
-
WT-5485 Fix test_hs09.py
-
- Closed
-
-
-
- Closed
-
- related to
-
-
- Closed
-
-
-
- Closed
-
-
WT-5540 Call cursor disable bulk insert on first insert to history store.
-
- Closed
-
-
WT-5512 Create a new history store cursor type that inserts/deletes by directly putting updates on the page
-
- Closed
-