You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It was invented to deal with recovery-resolving deadlocks possible only on (at
it seems) on 5+ nodes like
- 1 prepares T1 on 1, 2, 3
- 4 prepares conflicting T2 on 4, 5
- Everyone fails, and only 2, 3, 5 go up. They can't recover
without resolving at least one of xacts first because T1 and T2 conflict; and
'my orphaned xact which never got PRECOMMITted can be aborted directly'
doesn't help here as no T1 neigher T2 authored by live nodes.
To break out of this cycle, we could participate in voting normally, persisting
xact as in_table before even getting PREPARE. However, it was very cumbersome
and ugly; the process of in_table -> PREPARE state migration was especially
baroque. Implementing accurately batch wal scan would also bring a lot of pain.
There is a better idea: use generations to directly abort one of the
xacts above. The connectivity clique forming majority will eventually elect its
generation in which one of the nodes will be donor, i.e. will be immediately
MTM_GEN_ONLINE. Any prepare which it doesn't have is subject to direct ABORT; it
is the fundamental property of generations that node which is online in
generation n has all committable PREPAREs of all <n gens.
0 commit comments