There is no check for NULL for a value returned by `ibuf_alloc`, the NULL will be passed to `memcpy()` if the aforementioned function will return a NULL. The patch fixes that by replacing `ibuf_alloc` with macros `xibuf_alloc` that never return NULL. Found by Svace. NO_CHANGELOG=codehealth NO_DOC=codehealth NO_TEST=codehealth (cherry picked from commit b4ee146fde6e418aed590ac6054cff75c2a59626)

This patch optimizes the process of collecting ACKs from replicas for synchronous transactions. Before this patch, collecting confirmations was slow in some cases. There was a possible situation where it was necessary to go through the entire limbo again every time the next ACK was received from the replica. This was especially noticeable in the case of a large number of parallel synchronous requests. For example, in the 1mops_write bench with parameters --fibers=6000 --ops=1000000 --transaction=1, performance increases by 13-18 times on small clusters of 2-4 nodes and 2 times on large clusters of 31 nodes. Closes #9917 NO_DOC=performance improvement NO_TEST=performance improvement (cherry picked from commit 4a866f64d64c610a3c8441835fee3d8dda5eca71)

Two new vclock methods have been added: `vclock_nth_element` and `vclock_count_ge`. * `vclock_nth_element` takes n and returns whatever element would occur in nth position if vclock were sorted. This method is very useful for synchronous replication because it can be used to find out the lsn of the last confirmed transaction - it's simply the result of calling this method with argument {vclock_size - replication_synchro_quorum} (provided that vclock_size >= replication synchro quorum, otherwise it is obvious that no transaction has yet been confirmed). * `vclock_count_ge` takes lsn and returns the number of components whose value is greater than or equal to lsn. This can be useful to understand how many replicas have already received a transaction with a given lsn. Part of #9917 NO_CHANGELOG=Will be added in another commit NO_DOC=internal (cherry picked from commit 58f3c93b660499e85f08a4f63373040bcae28732)

According to the C standard, passing `NULL` to `memcpy` is UB, even if it copies nothing (number of bytes to copy is 0). The commit fixes such situation in memtx MVCC. Closes tarantool/security#129 NO_TEST=fix UB NO_CHANGELOG=fix UB NO_DOC=fix UB

In 6d88274 we rewrote Lua module `internal.trigger` that is used in `net.box` and possibly some external modules. Old implementation held all triggers in a Lua table, so deleting a trigger on the fly wasn't a problem. Now we store all triggers in a list and simply iterate over it when the triggers are fired, so the trigger list became non-resistent to modifications on the fly. In order to fix it, let's simply use `trigger_run` - it is resistant to the list modifications. Closes #10622 NO_DOC=bugfix (cherry picked from commit 78cfc5ef4cf43bf9d53dc51d0f843bee350609fd)

This patch eliminates flaking in the `gh_9918_synchro_queue_additional_info_test.lua` test. The problem was that the test did not wait for the connection between master and replica to be established, and therefore master node was in the "orphan" state at the time `box.ctl.promote()` was called. Thus, it turned out that the master node became the owner of the limbo, but was still read only. To fix this, this patch simply calls `cg.replica_set:wait_for_fullmesh()` on the previous line before `box.ctl.promote()`. Closes #10463 NO_DOC=test fix NO_CHANGELOG=test fix (cherry picked from commit 37bf64b7d7f76ea3330909655da90d64d0add558)

Since commit e19bca5a74e8 ("box: check fiber slice in generic implementation of index count"), Vinyl's version of `index.count()` checks the fiber slice. As a result, the test may fail if it runs under a heavy load: ``` | @@ -94,6 +94,7 @@ | end | end; | | --- | + | - error: fiber slice is exceeded | | ... | -- Verify that at any moment max index is corresponding to amount of tuples, | -- which means that changes apply order is correct ``` Let's set the max fiber slice to a big value to avoid that. NO_DOC=test fix NO_CHANGELOG=test fix (cherry picked from commit b5fb66437a22ea65ed27c2ed14636e8036b079d3)

The new version of the publishing action leads to the following error: NOWRAP ``` Error: File not found: '/home/runner/work/_actions/JamesIves/github-pages-deploy-action/v4.6.6/lib/main.js' ``` NOWRAP Let's revert it to v4.6.4 (because v4.6.5 change was reverted in v4.6.6). See also https://github.com/JamesIves/github-pages-deploy-action/issues/1697 NO_DOC=no code changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC (cherry picked from commit 7cf41a1bb9b3f0a2eac82c296a764688f5d8b35c)

The `ubuntu-latest` image is now `ubuntu-24.04`, see [1]. The job fails on this image with the following error: NOWRAP ``` CMake Error at /usr/local/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:233 (message): Could NOT find Readline (missing: READLINE_INCLUDE_DIR READLINE_LIBRARY) ``` NOWRAP It seems, the libreadline-dev package is missing. Let's install it. Also, update a version of the publishing action to the latest at the moment. I didn't perform any check, but I guess that a new version of NodeJS is needed and the latest action version has better support of it. [1]: https://github.blog/changelog/2024-09-25-actions-new-images-and-ubuntu-latest-changes/ NO_DOC=no code changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC (cherry picked from commit 3e09e9f293925195ddebb13a4fcfd64762e52b89)

Vinyl doesn't support altering the primary index of a non-empty space, but the check forbidding this isn't entirely reliable - the DDL function may yield to wait for pending WAL writes to finish after ensuring that the space doesn't contain any tuples. If a new tuples is inserted into the space in the meantime, the DDL operation will proceed rebuilding the primary index and trigger a crash because the code is written on the assumption that it's rebuilding a secondary index: ``` ./src/box/vinyl.c:1572: vy_check_is_unique_secondary_one: Assertion `lsm->index_id > 0' failed. ``` Let's fix this by moving the check after syncing on WAL. Closes #10603 NO_DOC=bug fix (cherry picked from commit 955537b57c2aade58b7ca42501a9bbe50dd91f26)