Skip to content
Snippets Groups Projects
Select Git revision
  • sd/tuple_buf
  • 2.11.5-picodata default protected
  • sd/execute_result
  • gmoshkin/more-backports
  • gmoshkin/more-backports-WIP
  • sd/heap-after-free
  • 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
  • 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 produce deferred DELETE on commit if key isn't updated
Vladimir Davydov authored 
Consider the following example:

  s = box.schema.space.create('test', {engine = 'vinyl'})
  s:create_index('primary')
  s:create_index('secondary', {parts = {2, 'unsigned'}})

  s:insert{1, 1, 1}
  s:replace{1, 1, 2}

When REPLACE{1,1} is committed to the secondary index, the overwritten
tuple, i.e. INSERT{1,1}, is found in the primary index memory, and so
deferred DELETE{1,1} is generated right away and committed along with
REPLACE{1,1}. However, there's no need to commit anything to the
secondary index in this case, because its key isn't updated. Apart from
eating memory and loading disk, this also breaks index stats, as vy_tx
implementation doesn't expect two statements committed for the same key
in a single transaction.

Fix this by checking if there's a statement in the log for the deleted
key and if there's skipping them both as we do in the regular case, see
the comment in vy_tx_set.

Closes #3693
e2f5e1bc
History
user avatar e2f5e1bc
History
Name Last commit Last update
.github
FreeBSD/databases/tarantool
apk
cmake
debian
doc
extra
rpm
rump
src
test
third_party
test-run @ 453d2bf3
.appveyor.yml
.editorconfig
.gdbinit
.gitignore
.gitmodules
.travis.mk
.travis.yml
AUTHORS
CMakeLists.txt
Dockerfile.staticbuild
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

https://tarantool.io/en/

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:

  • ANSI SQL, including views, joins, referential and check constraints
  • MsgPack data format and MsgPack based client-server protocol
  • two data engines: 100% in-memory with optional persistence and an own implementation of LSM-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 application 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.io/en/download/.

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

Please report bugs at https://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!