- Sep 15, 2016
-
-
bigbes authored
-
Konstantin Osipov authored
-
Georgy Kirichenko authored
-
- Sep 14, 2016
-
-
Konstantin Osipov authored
-
bigbes authored
-
Konstantin Osipov authored
Index page size and range size are storage-level properties and can not change during index life time. Initialize these properties from global defaults at index creation time. This way they are not affected after restart with different global options. Remove "engine-level" options support from Lua, all options are known to us now that we ditched third party engines.
-
Vladislav Shpilevoy authored
Closes #1738
-
Vladislav Shpilevoy authored
Closes #1737
-
Konstantin Osipov authored
g/static inline/statis is easier than merging an old branch with a runaway trunk
-
Georgy Kirichenko authored
ops
-
Georgy Kirichenko authored
-
Vladimir Davydov authored
Do a proper roll back on dump/compact failure.
-
Ruben Ayrapetyan authored
Now, names of related interfaces, global variables and fields are based on "iterator". This is pure refactoring without any functional changes. Closes #1694
-
- Sep 13, 2016
-
-
bigbes authored
-
bigbes authored
-
Konstantin Osipov authored
The range iterator open function used an obsolete indicator for special key (NULL key), which led to selection of a wrong range in :max() query. The bug required a compaction process to trigger it, since when there was only 1 range max() naturally always got the last one. After compaction, range iterator open could yield a random range for the special key. Update errinj.test.lua to always trigger compaction.
-
Konstantin Osipov authored
-
Roman Tsisyk authored
Remove all ranges from scheduler before deleting index. Follow up 43ca199e
-
Konstantin Osipov authored
The merge iterator didn't take into account iterator diretion when merging its sources, and always used to return the smallest tuple among the alternatives. If iterator order is LT or LE, the biggest tuple should be returned instead.
-
Vladimir Davydov authored
We don't remove dead index's ranges from the scheduler heap after we scheduled a drop task for it - we only do it from the drop task itself. As a result, we can happily go and schedule another task for the index being already scheduled for destruction. This can result in the index->ref == 1 assertion being violated in vy_task_drop_execute() or memory corruption induced by use-after-free of a vy_index struct.
-
Vladimir Davydov authored
Switch to pointers from built-in structures range->i[01].
-
Roman Tsisyk authored
-
- Sep 12, 2016
-
-
Konstantin Osipov authored
* add a test case based on error injection * fix a few release mode warnings * the test case is still failing, depends on introduction of shadow memory indexes.
-
Roman Tsisyk authored
Use global queues for scheduling instead of per-index. Fixes #1708
-
Konstantin Osipov authored
-
Konstantin Osipov authored
Update test run (fixes the sporadic console handshake bug when running tests). Fixes gh-1163.
-
Vladislav Shpilevoy authored
-
Nick Zavaritsky authored
-
Svyatoslav Feldsherov authored
Closes #1599
-
Nick Zavaritsky authored
-
bigbes authored
-
- Sep 09, 2016
-
-
Konstantin Osipov authored
Don't access uninitialized memory in ev_io_closing(). anfds array is initialized with zeroes, when it's reallocated, but anfdmax is array size, not array last element, so anfds[anfdmax] is garbage. When we're "closing" an fd which has never been added to anfds (ev_io_start()) wasn't called for it), we must check that it's within array size boundaries first.
-
Konstantin Osipov authored
-
Vladimir Davydov authored
Since range_id_max is not updated, indexes created after recovery might get the same ids as recovered ones. If this happens, the next recovery will crash, because there will be two or more identical ids in the range index file.
-
Roman Tsisyk authored
Prepare for #1599
-
Alexandr Lyapunov authored
-
Vladimir Davydov authored
vy_range_redistribute() doesn't work correctly if ranges are not sorted in ascending order.
-
Vladislav Shpilevoy authored
-
Vladimir Davydov authored
vy_task_{dump,compact}_{execute,complete} serve as trivial wrappers for the functions doing real work. Let's fold them to make the code more straightforward. No functional changes intended. While we touch this code, let's also get rid of all the pointless unlikely's - after all the functions are not called from hot paths so there's no point in cluttering the code.
-
Vladimir Davydov authored
This is pure refactoring, isn't supposed to introduce any functional changes.
-