I've added a trait called `CursorTrait`. I know it's not a good name for
now, but I didn't know what tto change then enum `Cursor` to. This trait
wraps all common functionality, and some functionality that is yet too
specific that needs to be fixed.
This is needed in order to have layered cursors where for example,
MvccCursor will need a fallback BTreeCursor.
Closes#3660
Rollback shouldn't modify the row version chain. This is crucial for
implementing a Non-blocking row version chain in #3499
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3583
Yield is a completion that does not allocate any inner state. By design
it is completed from the start and has no errors. This allows lightly
yield without allocating any locks nor heap allocate inner state.
This PR add proper program abort in case of unfinished statement reset
and interruption.
Also, this PR makes rollback methods non-failing because otherwise of
their callers usually unclear (if rollback failed - what is the state of
statement/connection/transaction?)
Reviewed-by: Preston Thorpe <preston@turso.tech>
Closes#3591
Table ID is an opaque identifier that is only meaningful to the MV store.
Each checkpointed MVCC table corresponds to a single B-tree on the pager,
which naturally has a root page.
We cannot use root page as the MVCC table ID directly because:
- We assign table IDs during MVCC commit, but
- we commit pages to the pager only during checkpoint
which means the root page is not easily knowable ahead of time.
Hence, we:
- store the mapping between table id and btree rootpage
- sqlite_schema rows will have a negative rootpage column if the
table has not been checkpointed yet.
MVCC is like the annoying younger cousin (I know because I was him) that
needs to be treated differently. MVCC requires us to use root_pages that
might not be allocated yet, and the plan is to use negative root_pages
for that case. Therefore, we need i64 in order to fit this change.
If we open database and logical log is not empty we need to recover from
it. We also make sure a single recover executes concurrently and other
connections just wait for it to finish.
I also changed the fuzz tester to use `restart` instead of calling
`load_logical_log` manually to test this behaviour.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3359
## Description
Read transactions from logical log and load mvcc store based on the
contents onto transaction 0, which is the special transaction where we
will load all row versions that can be read by all new transactions.
## Todo
- [x] Testing for multiple transactions
- [ ] Lock multiple loading of same logical-log at the same time
- [x] Add column_count to format because if not it is hard to judge from
record alone.
- [x] Trim buffer read
I was thinking to implement the rest on another pr to not increase load
to review this one.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3323
performs a blocking, truncating checkpoint:
- when started, blocks any other transactions from starting
- writes all row versions to pager that havent already been
checkpointed
- flushes them to wal
- checkpoints wal to db
in the case of added/deleted rows in table id 1 (sqlite schema),
also creates/destroys btrees accordingly
this assigns "synthetic" root page numbers instead of using the pager
or btree cursors to allocate pages. Actual page allocation will only
happen during checkpoint, since regular MVCC commit bypasses the
pager.
