MVCC sometimes loses gap record #8326

alyapunov · 2023-02-15T15:54:06Z

Simple reproduce:

box.cfg{memtx_use_mvcc_engine = true}

s = box.schema.space.create('test')
s:create_index('pk', {parts = {{1, 'uint'}, {2, 'uint'}}})

txn_proxy = require('txn_proxy')

tx1 = txn_proxy.new()
tx2 = txn_proxy.new()

tx1:begin()
tx2:begin()

tx1('s:select{1}') -- select by partial key {1}, empty result
tx1('s:replace{1, 1, 1}') -- write right to selected interval

tx2('s:replace{1, 1, 2}') -- overwrite by the second transaction
tx2:commit() -- ok, now tx1 must become conflicted because of the first select

tx1:commit() -- must fail, but it succeeds
s:select{1} -- must have {1, 1, 2}, but it's {1, 1, 1}

By a mistake in 8a56514 a shortcut was added to procedure that handles gap write: it was considered that if the writing transaction is the same as reading - there is no actual conflict that must be stored further. That was a wrong desision: if such a transaction yields and another transaction comes and commits a value with the same key - the first one must go to conflicted state since it has read no more possible state. Fix it, reverting the prevous changes and add a test. Closes tarantool#8326 NO_DOC=bugfix

By a mistake in 8a56514 a shortcut was added to procedure that handles gap write: it was considered that if the writing transaction is the same as reading - there is no actual conflict that must be stored further. That was a wrong decision: if such a transaction yields and another transaction comes and commits a value with the same key - the first one must go to conflicted state since it has read no more possible state. Fix it, reverting the previous changes and add a test. Closes tarantool#8326 NO_DOC=bugfix

Co-authored-by: Pavel Semyonov <p.semyonov@vk.team>

By a mistake in 8a56514 a shortcut was added to procedure that handles gap write: it was considered that if the writing transaction is the same as reading - there is no actual conflict that must be stored further. That was a wrong decision: if such a transaction yields and another transaction comes and commits a value with the same key - the first one must go to conflicted state since it has read no more possible state. Fix it, reverting the previous changes and add a test. Closes tarantool#8326 NO_DOC=bugfix

By a mistake in 8a56514 a shortcut was added to procedure that handles gap write: it was considered that if the writing transaction is the same as reading - there is no actual conflict that must be stored further. That was a wrong decision: if such a transaction yields and another transaction comes and commits a value with the same key - the first one must go to conflicted state since it has read no more possible state. Another similar mistake was made in e6f5090, where writing after full scan of the same transaction was not tracked as read. Obviously that was wrong: if some other transaction overwrites the key and commits - this transaction must go to read view since it did not see anything by this key which is not so anymore. Fix it, reverting the first commit and an modifying the second and add a test. Closes tarantool#8326 NO_DOC=bugfix

By a mistake in 8a56514 a shortcut was added to procedure that handles gap write: it was considered that if the writing transaction is the same as reading - there is no actual conflict that must be stored further. That was a wrong decision: if such a transaction yields and another transaction comes and commits a value with the same key - the first one must go to conflicted state since it has read no more possible state. Another similar mistake was made in e6f5090, where writing after full scan of the same transaction was not tracked as read. Obviously that was wrong: if some other transaction overwrites the key and commits - this transaction must go to read view since it did not see anything by this key which is not so anymore. Fix it, reverting the first commit and an modifying the second and add a test. Closes #8326 NO_DOC=bugfix

By a mistake in 8a56514 a shortcut was added to procedure that handles gap write: it was considered that if the writing transaction is the same as reading - there is no actual conflict that must be stored further. That was a wrong decision: if such a transaction yields and another transaction comes and commits a value with the same key - the first one must go to conflicted state since it has read no more possible state. Another similar mistake was made in e6f5090, where writing after full scan of the same transaction was not tracked as read. Obviously that was wrong: if some other transaction overwrites the key and commits - this transaction must go to read view since it did not see anything by this key which is not so anymore. Fix it, reverting the first commit and an modifying the second and add a test. Closes tarantool#8326 NO_DOC=bugfix (cherry picked from commit b41c454)

By a mistake in 8a56514 a shortcut was added to procedure that handles gap write: it was considered that if the writing transaction is the same as reading - there is no actual conflict that must be stored further. That was a wrong decision: if such a transaction yields and another transaction comes and commits a value with the same key - the first one must go to conflicted state since it has read no more possible state. Another similar mistake was made in e6f5090, where writing after full scan of the same transaction was not tracked as read. Obviously that was wrong: if some other transaction overwrites the key and commits - this transaction must go to read view since it did not see anything by this key which is not so anymore. Fix it, reverting the first commit and an modifying the second and add a test. Closes #8326 NO_DOC=bugfix (cherry picked from commit b41c454)

By a mistake in 8a56514 a shortcut was added to procedure that handles gap write: it was considered that if the writing transaction is the same as reading - there is no actual conflict that must be stored further. That was a wrong decision: if such a transaction yields and another transaction comes and commits a value with the same key - the first one must go to conflicted state since it has read no more possible state. Another similar mistake was made in e6f5090, where writing after full scan of the same transaction was not tracked as read. Obviously that was wrong: if some other transaction overwrites the key and commits - this transaction must go to read view since it did not see anything by this key which is not so anymore. Fix it, reverting the first commit and an modifying the second and add a test. Closes tarantool#8326 NO_DOC=bugfix (cherry picked from commit b41c454)

By a mistake in 8a56514 a shortcut was added to procedure that handles gap write: it was considered that if the writing transaction is the same as reading - there is no actual conflict that must be stored further. That was a wrong decision: if such a transaction yields and another transaction comes and commits a value with the same key - the first one must go to conflicted state since it has read no more possible state. Another similar mistake was made in e6f5090, where writing after full scan of the same transaction was not tracked as read. Obviously that was wrong: if some other transaction overwrites the key and commits - this transaction must go to read view since it did not see anything by this key which is not so anymore. Fix it, reverting the first commit and an modifying the second and add a test. Closes #8326 NO_DOC=bugfix (cherry picked from commit b41c454)

alyapunov added the bug Something isn't working label Feb 15, 2023

alyapunov self-assigned this Feb 15, 2023

alyapunov mentioned this issue May 16, 2023

memtx: mvcc abort readers of prepared #8665

Merged

kyukhin added the 2.10 Target is 2.10 and all newer release/master branches label May 17, 2023

alyapunov added a commit to alyapunov/tarantool that referenced this issue Jun 7, 2023

Update changelogs/unreleased/tarantoolgh-8326-mvcc-lost-gap-record.md

bff89e2

Co-authored-by: Pavel Semyonov <p.semyonov@vk.team>

alyapunov closed this as completed in #8665 Jun 21, 2023

alyapunov mentioned this issue Jun 21, 2023

Gh 8654 memtx mvcc abort readers of prepared 2.11 #8796

Merged

alyapunov mentioned this issue Jun 23, 2023

Gh 8654 memtx mvcc abort readers of prepared 2.10 #8806

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MVCC sometimes loses gap record #8326

MVCC sometimes loses gap record #8326

alyapunov commented Feb 15, 2023

MVCC sometimes loses gap record #8326

MVCC sometimes loses gap record #8326

Comments

alyapunov commented Feb 15, 2023