interior index cells have values that are not in the leaves, e.g.
(interior: 3)
/ \
(leaf: 2) (leaf: 4)
so their values need to be emitted after the left subtree is emitted.
Closes#351
NextAwait's next instruction was pointing to RewindAwait earlier which
is not current. The instruction now points to the instruction after
RewindAwait, which will be the loop body. Hence, rename rewind_labels to
scan_loop_body_labels to make it clearer
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#354
Closes#351
NextAwait's next instruction was pointing to RewindAwait earlier which
is not current. The instruction now points to the instruction after
RewindAwait, which will be the loop body. Hence, rename rewind_labels to
scan_loop_body_labels to make it clearer
Add a `pending_ops` field to `InnerLinuxIO` struct which is incremented
for each operation submitted to the ring and decremented when they are
taken off the completion queue. With this, we can exit from run_once if
there are no pending operations. Otherwise, in that case, it would hang
indefinitely due to call of `ring.submit_and_wait(1)`
Closes#349
Adds a struct WrappedIOUring which contains a IoUring and a pending_ops
field. Entry submission and popping from the queue is done through
functions operating on it, which also maintains pending_ops count
NOTE: This is a bit weird/hacky since in get_completion we create a
CompletionQueue and just call its next(). If it were a normal iterator
it would always return the same first item. However it is a queue posing
as an iterator which makes this work.
Add a `pending_ops` field to `InnerLinuxIO` struct which is incremented
for each operation submitted to the ring and decremented when they are
taken off the completion queue. With this, we can exit from run_once if
there are no pending operations. Otherwise, in that case, it would hang
indefinitely due to call of `ring.submit_and_wait(1)`
This is not related to any open issue (atleast from the ones I saw).
This is related to an issue I saw when running the simulator as it was
calling `io.run_once()` even before submitting any read/write job. This
would lead to it hanging since io_uring's submit_and_wait would keep
waiting for a completion event.
I've tried to improve the simulator's IO handling a bit:
We inject a fault before calling next_row() through which we'll get
pread faults. Also we call io's run_once on getting RowResult::IO. This
is run with a fault probability of 1%. This is less because a fault here
would result us in terminating the entire loop iterating on rows, and
also because realistically we'll expect less faults here.
PS: I think run_once() should not hang either when no operation is
pending in io_uring. Opened #349 for fixing that.
Closes#348
We inject fault before calling next_row() through which we'll get pread
faults. Also we call io's run_once on getting RowResult::IO. This is run
with a fault probability of 1%. This is less because a fault here would
result us in terminating the entire loop iterating on rows, and also
because realistically we'll expect less faults here
In the current implementation, there is an issue with the `min`/`max`
functions when the input contains both numbers and text. This merge
request fixes the problem.
I have also changed the `minmax` function by splitting it into two
separate functions to be able to add unit tests for both functions, just
like for the other functions
Closes#347
- Limbo command line shell supports e.g. `SELECT x'616263';`
- `EXPLAIN SELECT x'616263';` lists the opcode
Missing:
- Command line shell not entirely compatible with SQLite when blobs have
non-printable characters in the middle (e.g. `SELECT x'610062';`)
- Python bindings not supported (incoming soon)
Closes#343
- Limbo command line shell supports e.g. `SELECT x'616263';`
- `EXPLAIN SELECT x'616263';` lists the opcode
Missing:
- Command line shell not entirely compatible with SQLite when blobs have
non-printable characters in the middle (e.g. `SELECT x'610062';`)
- Python bindings not supported (incoming soon)
