tarantool / tarantool / 9495574802

87%

master: 88%

Build Type

push

github

Committed by sergepetrenko

Commit Message

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

(cherry picked from commit 1f75231a0)

Run Details

67380 of 119893 branches covered (56.2%)

8 of 8 new or added lines in 2 files covered. (100.0%)

44 existing lines in 13 files now uncovered.

100098 of 114979 relevant lines covered (87.06%)

2470049.04 hits per line