feat(tree): schedule block removal on disk reorgs #10603
Conversation
Rjected
added
C-enhancement
Rjected
force-pushed
the
dan/remove-blocks-reorg
branch
from
726165d
to
74808b2
Compare
| debug!(target: "engine", "Returned empty set of blocks to persist"); | ||
| } else { | ||
| if !self.persistence_state.in_progress() { | ||
| if let Some(new_tip_num) = self.persistence_state.remove_above_state.take() { | ||
| debug!(target: "engine", ?new_tip_num, "Removing blocks using persistence task"); |
There was a problem hiding this comment.
could we also track the distance here: last_persisted - new_tip
| // TODO: what about multiple on-disk reorgs in a row? | ||
| self.remove_above_state = Some(new_tip_num); |
There was a problem hiding this comment.
this could happen if there's a reorg immediately followed by another reorg while we're reorging on disk, right?
I assume what we'd need to do here is tracking the in progress remove_above_state and compare the new_tip_num against this, if the new_tip_num is lower, only then do we need a followup?
but perhaps this should instead be checked in on_disk_reorg function?
There was a problem hiding this comment.
here we should take a min of existing target block and incoming
| // TODO: what about multiple on-disk reorgs in a row? | ||
| self.remove_above_state = Some(new_tip_num); |
There was a problem hiding this comment.
here we should take a min of existing target block and incoming
Rjected
force-pushed
the
dan/remove-blocks-reorg
branch
4 times, most recently
from
38318a5
to
dc07855
Compare
Rjected
force-pushed
the
dan/remove-blocks-reorg
branch
from
dc07855
to
e7bb51d
Compare
|
Going to merge this as I end up improving on this in #10678 |
This introduces
is_disk_reorg, and adds a field toPersistenceStatethat tracks whether or not a block removal operation has been requested due to an on-disk reorg.The persistence task has been modified to return the hash of the new tip number, so that the engine can track the last persisted block and hash in a consistent way.