Commits
- Commit:
11ad946bc711ef032a70a9ae6ddf158e6b32680c
- From:
- Sergey Bronnikov <sergeyb@tarantool.org>
- Date:
test/fuzz: fix the CMake warning
CMake 3.29.0 produces a warning on configuration stage:
| CMake Warning (dev) in cmake/ProtobufMutator.cmake:
| A logical block opening on the line
| /home/sergeyb/sources/MRG/tarantool/cmake/ProtobufMutator.cmake:38 (if)
| closes on the line
| /home/sergeyb/sources/MRG/tarantool/cmake/ProtobufMutator.cmake:40 (endif)
| with mis-matching arguments.
The patch fixes the warning.
NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build
- Commit:
389a27db425c3f9c341b6e2ede3fe3bd86b62264
- From:
- Sergey Bronnikov <sergeyb@tarantool.org>
- Date:
cmake: fix building statically by Ninja
An attempt to build Tarantool statically by Ninja (with the
enabled CMake option BUILD_STATIC_WITH_BUNDLED_LIBS), error below
is produced:
| ninja: error: build.ninja:1405: bad $-escape
| (literal $ must be written as $$)
The commit fixes that error. Follows up commit c92a1699d6c8
("cmake: support build using Ninja").
NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build
- Commit:
806f050b5ea6147fb7b364ee69348a1016e6e8cf
- From:
- Sergey Bronnikov <sergeyb@tarantool.org>
- Date:
cmake: fix warning in an ExternalProject_Add()
CMake 3.24+ produces a warning about the missed option
DOWNLOAD_EXTRACT_TIMESTAMP in `ExternalProject_Add()` [1]:
| The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy
| CMP0135 is not set.
Documentation about policy CMP0135 [2] said:
CMake 3.23 and below set the timestamps of the extracted contents
to the same as the timestamps in the archive. When the URL
changes, the new archive is downloaded and extracted, but the
timestamps of the extracted contents might not be newer than the
previous contents. Anything that depends on the extracted contents
might not be rebuilt, even though the contents may change.
CMake 3.24 and above prefer to set the timestamps of all
extracted contents to the time of the extraction. This ensures
that anything that depends on the extracted contents will be
rebuilt whenever the URL changes.
1. https://cmake.org/cmake/help/latest/module/ExternalProject.html#url
2. https://cmake.org/cmake/help/latest/policy/CMP0135.html
NO_CHANGELOG=build
NO_DOC=build
NO_TEST=build
- Commit:
1f75231a0c0ce062e08660e0bc51485f7086412c
- From:
- Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
- Date:
relay: do not report vclock[0] anywhere
Remote replica's vclock is given to master to send data starting
from that position. The master does that, but, in order to find
the relevant position in local WAL to start from, the master must
ignore the local rows. Consider them all already "sent". For that
the master replaces the remote vclock[0] with the local vclock[0].
That makes xlog cursor skip all the local rows.
The problem is that this vclock was taken by relay as is, like if
it was truly reported by the replica. It was even saved as the
"last received ACK". Which clearly isn't the case.
When a real ACK was received, it didn't contain anything in
vclock[0], and yet relay "saw" that the previous ACK has
vclock[0] > 0. That looked like the replica went backwards without
even closing connection, which isn't possible. That made the relay
crash from cringe (on assert).
The fix is not to save the local vclock[0] in the last received
ACK.
For GC and xlog cursor the hack is still needed. An option how to
make it easier was to set vclock[0] to INT64_MAX to just never
even bother with any local rows, but that didn't work. Some
assumptions in other places seem to depend on having a proper
local LSN in these places.
Closes #10047
NO_CHANGELOG=the bug wasn't released
NO_DOC=bugfix
- Commit:
5ebbed7711d442e9b5ea21703c4aa5ba613a1a5d
- From:
- Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
- Date:
relay: rename vclock args and make const
It wasn't clear which of them are inputs and which are outputs.
The patch explicitly marks the input vclocks as const. It makes
the code a bit easier to read inside of relay.cc knowing that
these vclocks shouldn't change.
Alongside "replica_clock" in subscribe is renamed to
"start_vclock". To make it consistent with relay_final_join(), and
to signify that technically it doesn't have to be a replica
vclock. It isn't really. Box.cc alters the replica's vclock before
giving it to relay, which means it is no longer "replica clock".
In scope of #10047
NO_TEST=refactoring
NO_CHANGELOG=refactoring
NO_DOC=refactoring