tarantool / tarantool / 22775810579 / 1

88%

master: 88%

push

github

limbo: don't wait for volatiles on promote/demote

PROMOTE/DEMOTE requests on prepare tried to wait for all limbo
entries to get fully persisted before the requests could be
applied.

The reason was that these requests are checking if their LSNs
actually do the expected thing. That is, either match the already
confirmed LSN, or affect some pending transactions.

The situation when a PROMOTE/DEMOTE has LSN > confirmed LSN but
there are no transactions affected by that usually means that such
transactions existed, but the current instance got them already
rolled back. Which in turn looks like a split-brain.

The waiting though also happened on the volatile entries. The ones
which were not even submitted to the journal anyway. And that
could lead to a deadlock. It was happening when the old leader had
some pending volatile txns in the limbo, got PROMOTE from a newer
leader, this PROMOTE started waiting on all the limbo entries to
get persisted, and these entries in turn couldn't make progress
either, because the current instance can't finish them on its
own.

As a temporary solution it should be enough to simply not wait for
the volatile entries. It is safe to roll them back anyway, and no
need to know their LSNs for that.

As an actual solution the limbo must get rid of any rollbacks that
aren't done by PROMOTE/DEMOTE. Which means removal of rollback by
timeout. This is the only case when the mentioned situation of
"old leader rolled something back on its own" can happen. This can
only be done starting 4.x.

Closes #12205

NO_DOC=bugfix

70427 of 118516 branches covered (59.42%)

105926 of 120840 relevant lines covered (87.66%)

1395469.56 hits per line