When applied these changes will tell the CGO toolchain on macOS
the default installation location for the headers and libs.
I've recently started playing around with FDB go bindings on my mac.
I've followed the tutorial to set everything up but whilst doing so
I've started getting some error messages like so:
/Users/sevki/go/pkg/mod/github.com/apple/foundationdb/bindings/go@v0.0.0-20200125010749-6945a6ea0141/src/fdb/cluster.go:26:11: fatal error: 'foundationdb/fdb_c.h' file not found
#include <foundationdb/fdb_c.h>
^~~~~~~~~~~~~~~~~~~~~~
These errors are most probably caused by me unsetting LDFLAGS, CFLAGS
globally as the installer installs the header files and the libraries
to sane default locations.
However, I believe explicitly telling the CGO toolchain here is a
better experience for using this library. While unsetting LDFLAGS
and CFLAGS is not a very smart thing to do, some IDEs and other build
tools make it very hard to pass environment variables to set in this
context.
The `gettid()` function is part of glibc 2.30[1]. I decided to keep the
`gettid` implementation here under a different name to remain compatible
to older glibc versions.
[1] https://sourceware.org/ml/libc-alpha/2019-08/msg00029.html
The storage queue is no longer going to be a problem failing tests. Now the
backup worker life cycle is tied with backup. So consistency check only happens
after the backup workload is done. Thus, we no longer need to save backup
progress when consistency check is running.
The backup worker needs to use this version for popping when running in a NOOP
mode. This option is added to GetReadVersionRequest and proxies will send back
minKnownCommittedVersion if the option is set.
Also add a couple of knobs for backup workers.
The backup worker just blindly pop tags if the "backupStartedKey" is not set.
Note the commit version from TLog cannot be used as the pop version, because
for a single region, during a recovery the log router tags are used to recover
mutations. The backup worker can potentially pop mutations that are needed for
recovery, causing consistency errors. So the solution for now is to use commit
version - 5,000,000, which is a version guaranteed to be persisted on all
replicas.
This bug was introduced when I added log router tags unconditionally to any
configurations. In newEpoch(), the wait for remote recovery is conditioned on
"logRouterTags == 0", which always becomes false. Thus remote recovery was not
performed and remote TLogs won't copy data from previous epoch's TLogs
(previous epoch is a single region configuration). As a result, storage servers
cannot peek/get the data, and won't pop tags. Thus, waitForFullReplication()
became stuck and eventually test timeout.
sevki