core, eth, les: support resuming fast sync on heavy rollback (#3743)
This commit is contained in:
committed by
Felix Lange
parent
06d6685eb5
commit
9b84caf3a5
@ -175,6 +175,14 @@ func (pm *ProtocolManager) synchronise(peer *peer) {
|
||||
// Otherwise try to sync with the downloader
|
||||
mode := downloader.FullSync
|
||||
if atomic.LoadUint32(&pm.fastSync) == 1 {
|
||||
// Fast sync was explicitly requested, and explicitly granted
|
||||
mode = downloader.FastSync
|
||||
} else if currentBlock.NumberU64() == 0 && pm.blockchain.CurrentFastBlock().NumberU64() > 0 {
|
||||
// The database seems empty as the current block is the genesis. Yet the fast
|
||||
// block is ahead, so fast sync was enabled for this node at a certain point.
|
||||
// The only scenario where this can happen is if the user manually (or via a
|
||||
// bad block) rolled back a fast sync node below the sync point. In this case
|
||||
// however it's safe to reenable fast sync.
|
||||
mode = downloader.FastSync
|
||||
}
|
||||
if err := pm.downloader.Synchronise(peer.id, pHead, pTd, mode); err != nil {
|
||||
|
Reference in New Issue
Block a user