Skip to content
Snippets Groups Projects
Select Git revision
  • 2.11.5-picodata default protected
  • sd/exec
  • funbringer/2.11.5-fix-select-param-having
  • sd/small_tuple
  • sd/tuple_buf
  • sd/execute_result
  • gmoshkin/more-backports
  • gmoshkin/more-backports-WIP
  • 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
  • ekhamitov/sd/window-v2
  • vshunkov/fix_path protected
  • 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: create files for empty runs
Vladimir Davydov authored 
When we finally start storing vinyl metadata in a memtx table, we will
create an entry for a run as soon as we add the in-memory index which is
going to become the run after it's dumped. On recovery, we won't replay
xlog rows which add statements to in-memory indexes that have already
been dumped. We are planning to detect this by checking if the in-memory
index has a file on disk. To be able to do this in case all entries in a
range cancel each other on dump, we need to create files for empty runs.

Note, although we could delete empty runs from memory right away, we'll
need to have all runs when we switch to storing vinyl metadata in memtx,
including empty ones, on the list so that we can delete records from the
memtx table when they get compacted. In order not to break read/write
iterator assumptions, just skip empty runs when opening an iterator.
490028ac
History
user avatar 490028ac
History
Name Last commit Last update
FreeBSD/databases/tarantool
cmake
debian
doc
extra
rpm
src
test
third_party
test-run @ c5a6a08b
.appveyor.yml
.build.mk
.gdbinit
.gitignore
.gitmodules
.travis.yml
AUTHORS
CMakeLists.txt
Doxyfile
Doxyfile.API.in
LICENSE
README.FreeBSD
README.MacOSX
README.md
TODO
snapcraft.yaml
README.md

tarantool

Coverage Status Gitter

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!