Fix static initialization order for maxAllowedVersion (#6570)

* Fix static initialization order for maxAllowedVersion

As it was defined, maxAllowedVerion was statically and globally initialized with a dependency on CLIENT_KNOBS. Initialization order was not spelled out and therefore this relied on chance specifics of order. In some cases these two were constructed in the wrong order and led to a segfault on startup. Fix by deferring initialization of maxAllowedVerion.

* Fix formatting with clang-format
This commit is contained in:
Ben Collins 2022-03-11 14:02:35 -05:00 committed by GitHub
parent 5d1affa2c2
commit 32f2731773
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 4 deletions

View File

@ -41,10 +41,6 @@
namespace {
const std::string kTracingTransactionIdKey = "transaction_id";
const std::string kTracingTokenKey = "token";
// Max version we can set for minRequiredCommitVersionKey,
// making sure the cluster can still be alive for 1000 years after the recovery
const Version maxAllowedVerion =
std::numeric_limits<int64_t>::max() - 1 - CLIENT_KNOBS->VERSIONS_PER_SECOND * 3600 * 24 * 365 * 1000;
static bool isAlphaNumeric(const std::string& key) {
// [A-Za-z0-9_]+
@ -1865,6 +1861,11 @@ Future<RangeResult> AdvanceVersionImpl::getRange(ReadYourWritesTransaction* ryw,
}
ACTOR static Future<Optional<std::string>> advanceVersionCommitActor(ReadYourWritesTransaction* ryw, Version v) {
// Max version we can set for minRequiredCommitVersionKey,
// making sure the cluster can still be alive for 1000 years after the recovery
static const Version maxAllowedVerion =
std::numeric_limits<int64_t>::max() - 1 - CLIENT_KNOBS->VERSIONS_PER_SECOND * 3600 * 24 * 365 * 1000;
ryw->getTransaction().setOption(FDBTransactionOptions::LOCK_AWARE);
ryw->getTransaction().setOption(FDBTransactionOptions::ACCESS_SYSTEM_KEYS);
TraceEvent(SevDebug, "AdvanceVersion").detail("MaxAllowedVersion", maxAllowedVerion);