memtx: fix test for gh5304 issue and memtx_space_is_recovering function
In previous version of patch we compared memtx state with MEMTX_FINAL_RECOVERY to check that memtx recovery completed. This is not quite true, memtx_state == MEMTX_FINAL_RECOVERY means that the recovery from snapshot is finished, but recovery from wals not. We need to compare memtx_state with MEMTX_OK to check that recovery totally finished. In previous test version on_replace trigger (created on _user space) is never called. It's because is_recovery_finished() always returns false: on_schema_init is invoked BEFORE user's data recovery process (so trigger is not created at all at this moment). In new test version you can see correct user case: we create on_replace trigger on _index system space, which replaces/inserts/updates tuples in temp and loc spaces. So each time user creates new space and index for it, trigger replaces/inserts/updates tuples in temp and loc spaces. Because trigger replaces/inserts/updates tuple with same primary key, we get error when insert trigger called. Follow-up #5304
Showing
- changelogs/unreleased/fix-is-recovering-function 4 additions, 0 deletionschangelogs/unreleased/fix-is-recovering-function
- src/box/lua/ctl.c 1 addition, 1 deletionsrc/box/lua/ctl.c
- src/box/memtx_space.h 1 addition, 1 deletionsrc/box/memtx_space.h
- test/box/gh-5304-insert_during_recovery.lua 6 additions, 4 deletionstest/box/gh-5304-insert_during_recovery.lua
- test/box/gh-5304-insert_during_recovery.result 108 additions, 0 deletionstest/box/gh-5304-insert_during_recovery.result
- test/box/gh-5304-insert_during_recovery.test.lua 35 additions, 0 deletionstest/box/gh-5304-insert_during_recovery.test.lua
Please register or sign in to comment