mvcc loses a committed tuple after a synchronous rollback #7930
Description
Bug description
Run tarantool repro.lua:
repro.lua
fiber = require('fiber')
box.cfg{
memtx_use_mvcc_engine = true,
replication_synchro_quorum = 2,
replication_synchro_timeout = 0.1,
}
box.once("bootstrap", function()
box.schema.space.create("sync", {is_sync = true})
box.schema.space.create("async")
box.space.sync:create_index("pk")
box.space.async:create_index("pk")
end)
box.ctl.promote()
box.space.async:replace{1, 0}
assert(box.space.async:get{1} ~= nil, "Data is in place")
fiber.create(function()
box.begin()
box.space.sync:replace{1}
box.space.async:update({1}, {{'+', 2, 1}})
box.commit()
end)
ok, err = pcall(function() box.space.async:update({1}, {{'+', 2, 1}}) end)
assert(not ok, "Transaction is rolled back due to synchro timeout")
assert(box.space.async:get{1} ~= nil, "Data is in place") Output will look like:
2022-11-11 17:03:55.914 [66149] main utils.c:489 E> LuajitError: repro.lua:30: Data is in place
box.space.async:get{1} returns {1, 0} on line 20, before the synchronous transaction is started. So it should read the same after the synchronous transaction is rolled back. Nevertheless, it returns nil on line 30, hence an assertion fires.
The snippet produces an xlog file with the following contents:
tarantoolctl cat --show-system 00000000000000000000.xlog
Processing file '00000000000000000000.xlog'
---
HEADER:
lsn: 1
replica_id: 1
type: REPLACE
timestamp: 1668175435.8116
BODY:
space_id: 272
tuple: ['oncebootstrap']
---
HEADER:
lsn: 2
replica_id: 1
type: UPDATE
timestamp: 1668175435.8119
BODY:
space_id: 272
index_base: 1
key: ['max_id']
tuple: [['+', 2, 1]]
---
HEADER:
lsn: 3
replica_id: 1
type: INSERT
timestamp: 1668175435.812
BODY:
space_id: 280
tuple: [512, 1, 'sync', 'memtx', 0, {'is_sync': true}, []]
---
HEADER:
lsn: 4
replica_id: 1
type: UPDATE
timestamp: 1668175435.8121
BODY:
space_id: 272
index_base: 1
key: ['max_id']
tuple: [['+', 2, 1]]
---
HEADER:
lsn: 5
replica_id: 1
type: INSERT
timestamp: 1668175435.8122
BODY:
space_id: 280
tuple: [513, 1, 'async', 'memtx', 0, {}, []]
---
HEADER:
lsn: 6
replica_id: 1
type: INSERT
timestamp: 1668175435.8128
BODY:
space_id: 288
tuple: [512, 0, 'pk', 'tree', {'unique': true}, [[0, 'unsigned']]]
---
HEADER:
lsn: 7
replica_id: 1
type: INSERT
timestamp: 1668175435.813
BODY:
space_id: 288
tuple: [513, 0, 'pk', 'tree', {'unique': true}, [[0, 'unsigned']]]
---
HEADER:
lsn: 1
group_id: 1
type: RAFT
timestamp: 1668175435.8131
BODY:
0: 2
---
HEADER:
lsn: 8
replica_id: 1
type: PROMOTE
timestamp: 1668175435.8132
BODY:
2: 0
3: 0
83: 2
---
HEADER:
lsn: 9
replica_id: 1
type: REPLACE
timestamp: 1668175435.8133
BODY:
space_id: 513
tuple: [1, 0]
---
HEADER:
lsn: 10
replica_id: 1
type: REPLACE
tsn: 10
timestamp: 1668175435.8135
BODY:
space_id: 512
tuple: [1]
---
HEADER:
lsn: 11
commit: true
replica_id: 1
type: UPDATE
tsn: 10
timestamp: 1668175435.8135
BODY:
space_id: 513
index_base: 1
key: [1]
tuple: [['+', 2, 1]]
---
HEADER:
lsn: 12
replica_id: 1
type: UPDATE
timestamp: 1668175435.8135
BODY:
space_id: 513
index_base: 1
key: [1]
tuple: [['+', 2, 1]]
---
HEADER:
lsn: 13
replica_id: 1
type: ROLLBACK
timestamp: 1668175435.9139
BODY:
- null
- 1
- 11
...
When this file is recovered with mvcc, the data is still missing:
Tarantool 2.11.0-entrypoint-696-g3d3e9dea1
type 'help' for interactive help
tarantool> box.cfg{memtx_use_mvcc_engine=true, log_level=1}
'strip_core' is set but unsupported
---
...
tarantool> box.space.async:fselect{}
---
- - +-----+
- |col1 |
- +-----+
- +-----+
...
But when the file is recovered without mvcc, the data is present:
Tarantool 2.11.0-entrypoint-696-g3d3e9dea1
type 'help' for interactive help
tarantool> box.cfg{log_level=1}
'strip_core' is set but unsupported
---
...
tarantool> box.space.async:fselect{}
---
- - +-----+-----+
- |col1 |col2 |
- +-----+-----+
- | 1 | 0 |
- +-----+-----+
...