[Tarantool-patches] [PATCH] limbo: introduce request processing hooks
Cyrill Gorcunov
gorcunov at gmail.com
Mon Jul 12 18:48:08 MSK 2021
Guys, there are some moments even in current code structure which
looks somehow strange so I would like to discuss them. Lets consider
the following case: one replic sends us a promote request (assume
we're sitting in term 2 and max term is 2).
applier 1
---------
applier_apply_tx
(promote term = 3
current max term = 2)
applier_synchro_filter_tx
apply_synchro_row
journal_write
(sleeping)
at this moment another applier comes in with obsolete
data and term 2
applier 2
---------
applier_apply_tx
(term 2)
applier_synchro_filter_tx
txn_limbo_is_replica_outdated -> false
journal_write (sleep)
applier 1
---------
journal wakes up
apply_synchro_row_cb
set max term to 3
return to applier read and
applier 2 could finish its write
and wake up too
at this moment the data from applier 2 is actually queued
for write as valid but we just wrote the term 3, so if we would
had been updating terms map earlier (before jornal write) the data
from applier 2 should be NOPified. I think there is some problem
because due to journal write lag the data is not as it could be
if terms map updated early. Serge, Vlad, am I right? Which consequences
can be here? IOW, should not we track terms earlier even without
my filter series?
More information about the Tarantool-patches
mailing list