Closes#2715
1. Since our multithreading isn't proven correct (and is actually
probably all kinds of incorrect), let's serialize these tests since they
operate on the same database
2. Use `lock()` instead of `try_lock()` - i.e. wait to obtain the lock
on the file instead of immediately erroring if we can't
Closes#2729
This kind of fault does not semantically represent anything real, since
we already have fault injection for every concrete IO operation like
reading, writing, syncing and so forth.
Moreover, having this feature is the direct cause of the false positive
simulator failure as reported in issue #2727. There, a "run_once fault"
happened immediately after we fsynced following an INSERT, which caused
the simulator to think the INSERT failed, and later a sim assertion
failed because the on-disk database had 1 more row than it thought it
would.
Closes#2727
Reviewed-by: Pekka Enberg <penberg@iki.fi>
Closes#2728
This kind of fault does not semantically represent anything real,
since we already have fault injection for every concrete IO operation
like reading, writing, syncing and so forth.
Moreover, having this feature is the direct cause of the false positive
simulator failure as reported in issue #2727. There, a "run_once fault"
happened immediately after we fsynced following an INSERT, which caused
the simulator to think the INSERT failed, and later a sim assertion failed
because the on-disk database had 1 more row than it thought it would.
Add `truncate` method in the page cache which remove all entries which
reference pages greater than new DB size.
This will be used in the sync engine as in its case DB size can shrink
when we "rebase" changes from remote to local.
It stands on the #2707 because touch few files from that PR
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2711
The Unix backend is a syscall()-based, blocking implementation. The
O_NONBLOCK adds nothing.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2708
