Skip to content
Snippets Groups Projects
Select Git revision
  • gmoshkin/more-backports
  • 2.11.5-picodata default protected
  • sd/64-bit
  • sd/wf_fixups protected
  • sd/c813750b7
  • funbringer/2.11.5-extend-op-result-row
  • gmoshkin/fix-window-in-subquery protected
  • sd/fix_r10
  • sd/window
  • sd/fix_sq
  • sd/fix_window_sq_panic
  • picodata-25.1
  • funbringer/2.11.5-fix-select-param-having
  • ekhamitov/sd/window-v2
  • vshunkov/fix_path protected
  • vshunkov/ci_sock
  • dec_vardir protected
  • vshunkov/fix_checkpatch
  • vshunkov/checkpatch
  • vshunkov/sock
  • 2.11.5 protected
  • 2.11.2.159 protected
  • 2.11.4 protected
  • 2.11.2.155 protected
  • 2.11.2.148 protected
  • 2.11.2.145 protected
  • 2.11.2.137 protected
  • 2.11.2.136 protected
  • 2.11.2.135 protected
  • 2.11.3 protected
  • 2.11.2.109 protected
  • 2.11.2.108 protected
  • 2.11.2.105 protected
  • 2.11.2.98 protected
  • 2.11.2.97 protected
  • 2.11.2.96 protected
  • 2.11.2.92 protected
  • 2.11.2 protected
  • 3.0.0-beta1 protected
  • 2.11.0.91 protected
40 results
Compare
user avatar
vinyl: don't advance read iterator pos after restore to min key
Vladimir Davydov authored 
If the iterator over a merge source was restored to a newer version of
the min key, we must not increment front_id, otherwise the source won't
be advanced on the next iteration, potentially resulting in the same key
returned twice by vy_merge_iterator_next_key(). In the long run, this is
likely to break the cache. Fix this and add an assert() checking that it
never happens.

While we are at it, remove loop from vy_read_iterator_merge_next_key()
that checks that the statement returned by vy_merge_iterator_next_key()
isn't the same as the statement returned to the user last time. The loop
condition should never evaluate to true, which is assured by the new
assert().

Fixes: 61ffe793 ("vinyl: fix read iterator restoration to a newer
version of the same key").
650f656e
History
user avatar 650f656e
History
Name Last commit Last update
FreeBSD/databases/tarantool
cmake
debian
doc
extra
rpm
rump
src
test
third_party
test-run @ a50b0b53
.appveyor.yml
.gdbinit
.gitignore
.gitmodules
.travis.mk
.travis.yml
AUTHORS
CMakeLists.txt
Doxyfile
Doxyfile.API.in
Jenkinsfile
LICENSE
README.FreeBSD
README.MacOSX
README.md
TODO
snapcraft.yaml
README.md

Tarantool

Build Status Code Coverage Telegram Slack Gitter Google Groups

http://tarantool.org

Tarantool is an in-memory database and application server.

Key features of the application server:

  • 100% compatible drop-in replacement for Lua 5.1, based on LuaJIT 2.1. Simply use #!/usr/bin/tarantool instead of #!/usr/bin/lua in your script.
  • full support for Lua modules and a rich set of own modules, including cooperative multitasking, non-blocking I/O, access to external databases, etc

Key features of the database:

  • MsgPack data format and MsgPack based client-server protocol
  • two data engines: 100% in-memory with optional persistence and a 2-level disk-based B-tree, to use with large data sets
  • multiple index types: HASH, TREE, RTREE, BITSET
  • asynchronous master-master replication
  • authentication and access control
  • the database is just a C extension to the app server and can be turned off

Supported platforms are Linux/x86 and FreeBSD/x86, Mac OS X.

Tarantool is ideal for data-enriched components of scalable Web architecture: queue servers, caches, stateful Web applications.

To download and install Tarantool as a binary package for your OS, please visit https://tarantool.org/download.html.

To build Tarantool from source, see detailed instructions in the Tarantool documentation at https://tarantool.org/doc/dev_guide/building_from_source.html.

Please report bugs at http://github.com/tarantool/tarantool/issues We also warmly welcome your feedback in the discussion mailing list, tarantool@googlegroups.com.

Thank you for your interest in Tarantool!