tarantool
/
tarantool
/
15390442403
88%
master: 88%
master: 88%
|
Ran
|
Jobs
1
|
Files
0
|
Run time
–
|
Badge
Embed ▾
README BADGES
|
push
github
lockerbox: handle stale multikey tuple fields After a multikey index is altered or dropped, tuples that were inserted while it existed still reference the format with multikey parts. Actually, that multikey format field shouldn't be used anymore because multikey index is gone, but that's not true. It happens because format is arranged to a JSON tree, and this tree has an interesting property. Imagine having a field with path '[1][*]' in the tree. Then, when looking for a field '[1][1]' (or '[1]["abc"]', the second key can be anything), the field with path '[1][*]' will be returned since '*' is actually wildcard. Hence, even if the format is stale and there are no multikey fields in actual format, we can obtain a multikey field even if we didn't search for it and `multikey_idx` will be MULTIKEY_NONE in this case. Let's handle this scenario - simply ignore offset slot when `multikey_idx` is MULTIKEY_NONE for a multikey field. This bug could lead to assertion failure in Debug build and UB or even crash in Release build because when one builds an index over the field that was covered by multikey index, field map of tuples referencing the old format would be incorrect - it would store offset of multikey array instead of actual field. Closes #11291 NO_DOC=bugfix (cherry picked from commit 58c7b7905)
Jobs
| ID | Job ID | Ran | Files | Coverage | |
|---|---|---|---|---|---|
| 1 | 15390442403.1 | 518 |
87.53 |
GitHub Action Run |
Source Files on build 15390442403
Detailed source file information is not available for this build.