Previous attempt to fix flakiness in commit 6a2c73f81b30 ("test: fix flakiness in gh_6128_background_mode_test") used a constant buffer size in check_err_msg function. Tarantool 2.10 has a bit bigger log before a desired message that other versions of Tarantool and it leads to a this resulted in a truncated message ("entering the even" instead of "entering the event loop"). Patch replaces check_err_msg() implementation to grep_log used in luatest, it reads the whole log. Also patch renames check_err_msg to check_msg, because "entering the event loop" is not an error message. Follows up #6128 NO_CHANGELOG=fix test NO_DOC=fix test

Test runs an external process with tarantool that writes to a log file. Then test reads that log file and searches a string with required message in it (see function check_err_msg). Test was flaky on macOS and I suspect it was happening due to a high log level - timeout was not enough to wait message in the log file. Patch decreases a log level to a default value and replaces io functions with the similar alternatives in a fio module. Using fio functions allows to not block fibers. NO_CHANGELOG=test fix NO_DOC=test fix (cherry picked from commit 47380bb7626544800239ca179a6b2c490ebb6d1c)

The xlog reader Lua module uses the xlog_cursor_next_row, which decodes the row header with xrow_header_decode. The latter silently ignores any unknown fields, which complicates catching bugs when garbage is written to a row header by mistake, for example, see #8783. Let's parse a row header without using xrow_header_decode in the xlog reader module, like we parse a row body, and output all unknown/invalid keys as is. To do that, we have to extend the xlog cursor API with the new method xlog_cursor_next_row_raw that returns a pointer to the position in the tx buffer where the next xrow is stored without advancing it. To avoid a memory leak in case the caller fails to parse an xrow returned by this function, we also have to move the call to xlog_tx_cursor_destroy from xlog_tx_cursor_next_row to xlog_cursor_next_tx. While we are at it, - Don't raise an error if a key type encountered in a row body is invalid (not an integer). Instead, silently ignore such keys. - Remove the useless body MsgPack validness check because we already check it after decoding the header. - Add error injection based tests to check all the corner cases. NO_DOC=bug fix (cherry picked from commit 8a25d170ea897d5aa2f1a81e1cbe8292596a6a6d)

To avoid garbage written to xlog. Closes #8783 NO_DOC=bug fix NO_TEST=next commit (cherry picked from commit f058cee74eca494e8fca8e3aae6b94ce8105165b)

<luaT_pushtuple> function created a new GCfunc object for a tuple __gc handler (i.e. <lbox_tuple_gc>), having no upvalues, on each call when tuple object for Lua world is created. The change introduces the reference to the single GCfunc object created on Tarantool startup and stored to Lua registry. Using this approach in scope of <luaT_pushtuple> is aimed to reduce Lua GC memory usage. Part of #5201 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring Reviewed-by: Vladimir Davydov <vdavydov@tarantool.org> Reviewed-by: Sergey Kaplun <skaplun@tarantool.org> Signed-off-by: Igor Munkin <imun@tarantool.org> (cherry picked from commit 8d7d14609853ac7020f15d5239ee05c65817ad29)

There's case when a transaction is rolled back from prepared state. This happens when WAL fails, synchronized replication confirmation failure or perhaps in other similar cases. By design other RW transactions and transactions with READ_COMMITTED isolation level are allowed to read prepared state. All these transactions must be aborted in case of rollback of prepared transaction since they definitely have read no more possible database state. This patch implements this abortion. Closed #8654 NO_DOC=bugfix (cherry picked from commit 54986902663db1e5d85525ab29499c4714bb3b73)

Rollback is rather complicated part if MVCC implementation that is meant to handle two kinds of rollback: * rollback from in-progress state, if box.rollback() is called. * rollback from prepared state, when WAL fails. Unfortunately the last one was not properly tested and surely has at least one flaw. When an inserting transaction becomes prepared its stories could be linked as deleted (via del_stmt pointer) by other in-progress transactions in order to maintain correct visibility. The problem is that in case of rollback of such prepared transaction those links remained. Broken links breaks the chain structure, and some older changes (that were linked as deleted before that hapless preparation) can become visible to other transaction. Refactor, simplify a bit that part of code and fix the issue described above; cover with tests. Closes #8648 NO_DOC=bugfix (cherry picked from commit 85569d9c2d75218fb402d74de0d159f1276123e3)

Almost completely rewrite, simplify and comment this part of code. Part of #8648 Part of #8654 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring (cherry picked from commit e90150746d68299d24d96c437776ee71483dcb88)

Almost completely rewrite, simplify and comment this part of code. Part of #8648 Part of #8654 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring (cherry picked from commit 63da3bed43e9dbdc765913f7419bf58e82d25e31)

The latter flag is a bit wider: it reveals not only inserting statements after deleting by the same transaction, but also replacing and deleting statements after all kinds of previois changes but the same transaction. This extended behavior will be used in further commits. Part of #8648 Part of #8654 NO_DOC=refactoring NO_TEST=refactoring NO_CHANGELOG=refactoring (cherry picked from commit 3cfa6756d31e3d215db7ad2c2714ac3bb473d66b)