MinSafeTS might be set to MaxUint64 permanently

[JmPotato]

If the cluster just bootstraps and the min-resolved-ts hasn't been initialized yet, MinSafeTS might be set to MaxUint64. And since the MinSafeTS is not allowed to fall back, it will remain being this value permanently.

client-go/tikv/kv.go

Lines 546 to 563 in c8832b8

	func (s *KVStore) updateMinSafeTS(txnScope string, storeIDs []uint64) {
	minSafeTS := uint64(math.MaxUint64)
	// when there is no store, return 0 in order to let minStartTS become startTS directly
	if len(storeIDs) < 1 {
	s.minSafeTS.Store(txnScope, 0)
	}
	for _, store := range storeIDs {
	ok, safeTS := s.getSafeTS(store)
	if ok {
	if safeTS != 0 && safeTS < minSafeTS {
	minSafeTS = safeTS
	}
	} else {
	minSafeTS = 0
	}
	}
	s.minSafeTS.Store(txnScope, minSafeTS)
	}

[jebter]

/label affects-7.1

[HuSharp]

The core question is the getter

• we introduce PD API to not execute go func which for KV request, resulting in not updating safeTSMap.
  • updateMinSafeTS relies on safeTSMap which makes sense(because actually, we can call updateMinSafeTS to kvReuqestUpdater[to indicate func base]).
• And we need to update minsafeTS to make sure when API fails we can fall back to the original way which is by kv request.
• But the core problem is: updateMinSafeTS will return maxUnit64 when the first kv request returns 0 and then although PD API returns correctly[maybe kv is not initialized], TS can not change maxUnit64.
  • to resolve this question, we need to regard maxUnit64 as 0 which means there is an initial state.

[HuSharp]

/label affects-6.5