Fix some typos.
This commit is contained in:
Bruce Mitchener
parent
e0c8175f3c
commit
9cdf25eda3
|
|
@ -111,7 +111,7 @@ func retryable(wrapped func() (interface{}, error), onError func(Error) FutureNi
|
|||
// retried or, if fatal, return the error to the caller.
|
||||
//
|
||||
// When working with Future objects in a transactional function, you may either
|
||||
// explicity check and return error values using Get, or call MustGet. Transact
|
||||
// explicitly check and return error values using Get, or call MustGet. Transact
|
||||
// will recover a panicked Error and either retry the transaction or return the
|
||||
// error.
|
||||
//
|
||||
|
|
@ -151,7 +151,7 @@ func (d Database) Transact(f func(Transaction) (interface{}, error)) (interface{
|
|||
// retried or, if fatal, return the error to the caller.
|
||||
//
|
||||
// When working with Future objects in a read-only transactional function, you
|
||||
// may either explicity check and return error values using Get, or call
|
||||
// may either explicitly check and return error values using Get, or call
|
||||
// MustGet. ReadTransact will recover a panicked Error and either retry the
|
||||
// transaction or return the error.
|
||||
//
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ The cluster file contains a connection string consisting of a cluster identifier
|
|||
|
||||
Together the ``description`` and the ``ID`` should uniquely identify a FoundationDB cluster.
|
||||
|
||||
A cluster file may contain comments, marked by the ``#`` character. All characters on a line after the first occurance of a ``#`` will be ignored.
|
||||
A cluster file may contain comments, marked by the ``#`` character. All characters on a line after the first occurrence of a ``#`` will be ignored.
|
||||
|
||||
Generally, a cluster file should not be modified manually. Incorrect modifications after a cluster is created could result in data loss. To change the set of coordination servers used by a cluster, see :ref:`configuration-choosing-coordination-servers`. To change the cluster ``description``, see :ref:`configuration-setting-cluster-description`.
|
||||
|
||||
|
|
@ -186,7 +186,7 @@ To temporarily or permanently remove one or more machines from a FoundationDB cl
|
|||
It is now safe to remove these machines or processes from the cluster.
|
||||
|
||||
|
||||
``exclude`` can be used to exclude either machines (by specifiying an IP address) or individual processes (by specificying an ``IP``:``PORT`` pair).
|
||||
``exclude`` can be used to exclude either machines (by specifying an IP address) or individual processes (by specifying an ``IP``:``PORT`` pair).
|
||||
|
||||
.. note:: Addresses have the form ``IP``:``PORT``. This form is used even if TLS is enabled.
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ There are 5 command line tools for working with Backup and DR operations:
|
|||
The backup agent is a daemon that actually executes the work of the backup and restore jobs. Any number of backup agents pointed at the same database will cooperate to perform backups and restores. The Backup URL specified for a backup or restore must be accessible by all ``backup_agent`` processes.
|
||||
|
||||
``fdbdr``
|
||||
This command line tool is used to control (but not execute) DR jobs - backups from one database to anothher. It can ``start``, ``abort`` a DR job, or ``switch`` the DR direction. It can also get the ``status`` of a running DR job.
|
||||
This command line tool is used to control (but not execute) DR jobs - backups from one database to another. It can ``start``, ``abort`` a DR job, or ``switch`` the DR direction. It can also get the ``status`` of a running DR job.
|
||||
|
||||
``dr_agent``
|
||||
The database backup agent is a daemon that actually executes the work of the DR jobs, writing snapshot and log data to the destination database. Any number of agents pointed at the same databases will cooperate to perform the backup.
|
||||
|
|
@ -193,7 +193,7 @@ The ``start`` subcommand is used to start a backup. If there is already a backu
|
|||
Perform the backup continuously rather than terminating once a restorable backup is achieved. Database mutations within the backup's target key ranges will be continuously written to the backup as well as repeated inconsistent snapshots at the configured snapshot rate.
|
||||
|
||||
``-s <DURATION>`` or ``--snapshot_interval <DURATION>``
|
||||
Specifies the duration, in seconds, of the inconsistent snapshots written to the backup in continous mode. The default is 864000 which is 10 days.
|
||||
Specifies the duration, in seconds, of the inconsistent snapshots written to the backup in continuous mode. The default is 864000 which is 10 days.
|
||||
|
||||
``-w``
|
||||
Wait for the backup to complete with behavior identical to that of the :ref:`wait command <backup-wait>`.
|
||||
|
|
@ -222,7 +222,7 @@ The ``abort`` subcommand is used to abort a backup that is currently in progress
|
|||
``discontinue``
|
||||
---------------
|
||||
|
||||
The ``discontinue`` subcommand is only available for backups that were started with the continuous (``-z``) option. Its effect is to discontinue the continous backup. Note that the subcommand does *not* abort the backup; it simply allows the backup to complete as a noncontinuous backup would.
|
||||
The ``discontinue`` subcommand is only available for backups that were started with the continuous (``-z``) option. Its effect is to discontinue the continuous backup. Note that the subcommand does *not* abort the backup; it simply allows the backup to complete as a noncontinuous backup would.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -287,7 +287,7 @@ The expiration CUTOFF must be specified by one of the two following arguments:
|
|||
``--expire_before_version <VERSION>``
|
||||
Specifies the cutoff by a database commit version.
|
||||
|
||||
Optionally, the user can specify a minimum RESTORABILITY guarauntee with one of the following options.
|
||||
Optionally, the user can specify a minimum RESTORABILITY guarantee with one of the following options.
|
||||
|
||||
``--restorable_after_timestamp <DATETIME>``
|
||||
Specifies that the backup must be restorable to DATETIME and later. Requires a cluster file and will use version/timestamp metadata in the database to convert DATETIME to a database commit version. DATETIME must be in the form "YYYY-MM-DD.HH:MI:SS" in UTC.
|
||||
|
|
@ -371,7 +371,7 @@ The ``start`` command will start a new restore on the specified (or default) tag
|
|||
Required. Specifies the Backup URL for the source backup data to restore to the database. The source data must be accessible by the ``backup_agent`` processes for the cluster.
|
||||
|
||||
``-w``
|
||||
Wait for the the restore to reach a final state (such as complete) before exiting. Prints a progress update every few seconds. Behavior is identical to that of the wait command.
|
||||
Wait for the restore to reach a final state (such as complete) before exiting. Prints a progress update every few seconds. Behavior is identical to that of the wait command.
|
||||
|
||||
``-k <KEYS>``
|
||||
Specify list of key ranges from the backup to restore to the database
|
||||
|
|
@ -443,7 +443,7 @@ The ``fdbdr`` command line tool is used to manage DR tasks.
|
|||
|
||||
user@host$ fdbdr [-h] <SUBCOMMAND> [<SUBCOMMAND_OPTIONS>] -d <CLUSTER_FILE> -s <CLUSTER_FILE> [-v]
|
||||
|
||||
The following arguments are used by mutiple subcommands:
|
||||
The following arguments are used by multiple subcommands:
|
||||
|
||||
``-h``
|
||||
Get help on the ``fdbdr`` command.
|
||||
|
|
@ -452,7 +452,7 @@ The following arguments are used by mutiple subcommands:
|
|||
Get the version of FoundationDB in use.
|
||||
|
||||
``-d <CLUSTER_FILE>``
|
||||
Specify the path to the ``fdb.cluster`` file for the destination cluster of the DR operaiton.
|
||||
Specify the path to the ``fdb.cluster`` file for the destination cluster of the DR operation.
|
||||
|
||||
``-s <CLUSTER_FILE>``
|
||||
Specify the path to the ``fdb.cluster`` file for the source cluster of the DR operation.
|
||||
|
|
@ -515,7 +515,7 @@ Unlike ``backup_agent``, ``dr_agent`` is not started automatically in a default
|
|||
Get the version of FoundationDB in use.
|
||||
|
||||
``-d <CLUSTER_FILE>``
|
||||
Specify the path to the ``fdb.cluster`` file for the destination cluster of the DR operaiton.
|
||||
Specify the path to the ``fdb.cluster`` file for the destination cluster of the DR operation.
|
||||
|
||||
``-s <CLUSTER_FILE>``
|
||||
Specify the path to the ``fdb.cluster`` file for the source cluster of the DR operation.
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ There is also a convenience option, ``coordinators auto``, that will automatical
|
|||
|
||||
.. note:: |coordinators-auto|
|
||||
|
||||
You can also change the cluster ``description``, as decribed in :ref:`configuration-setting-cluster-description`.
|
||||
You can also change the cluster ``description``, as described in :ref:`configuration-setting-cluster-description`.
|
||||
|
||||
Next steps
|
||||
==========
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Redundancy modes define storage requirements, required cluster size, and resilie
|
|||
* ``three_data_hall``
|
||||
* ``three_datacenter``
|
||||
|
||||
For descriptions of redundacy modes, see :ref:`configuration-choosing-redundancy-mode`.
|
||||
For descriptions of redundancy modes, see :ref:`configuration-choosing-redundancy-mode`.
|
||||
|
||||
storage engine
|
||||
^^^^^^^^^^^^^^^
|
||||
|
|
@ -108,7 +108,7 @@ The ``coordinators`` command is used to change cluster coordinators or descripti
|
|||
|
||||
Addresses may be specified as a list of IP:port pairs (such as ``coordinators 10.0.0.1:4000 10.0.0.2:4000 10.0.0.3:4000``). If addresses are specified, the coordinators will be set to them. An ``fdbserver`` process must be running on each of the specified addresses.
|
||||
|
||||
If ``auto`` is specified, coordinator addresses will be choosen automatically to support the configured redundancy level. (If the current set of coordinators are healthy and already support the configured redundancy level, nothing will be changed.)
|
||||
If ``auto`` is specified, coordinator addresses will be chosen automatically to support the configured redundancy level. (If the current set of coordinators are healthy and already support the configured redundancy level, nothing will be changed.)
|
||||
|
||||
For more information on setting coordinators, see :ref:`configuration-changing-coordination-servers`.
|
||||
|
||||
|
|
@ -194,7 +194,7 @@ The following options are available for use with the ``option`` command:
|
|||
|
||||
``READ_AHEAD_DISABLE`` - Disables read-ahead caching for range reads. Under normal operation, a transaction will read extra rows from the database into cache if range reads are used to page through a series of data one row at a time (i.e. if a range read with a one row limit is followed by another one row range read starting immediately after the result of the first).
|
||||
|
||||
``READ_YOUR_WRITES_DISABLE`` - Reads performed by a transaction will not see any prior mutations that occured in that transaction, instead seeing the value which was in the database at the transaction's read version. This option may provide a small performance benefit for the client, but also disables a number of client-side optimizations which are beneficial for transactions which tend to read and write the same keys within a single transaction.
|
||||
``READ_YOUR_WRITES_DISABLE`` - Reads performed by a transaction will not see any prior mutations that occurred in that transaction, instead seeing the value which was in the database at the transaction's read version. This option may provide a small performance benefit for the client, but also disables a number of client-side optimizations which are beneficial for transactions which tend to read and write the same keys within a single transaction.
|
||||
|
||||
``RETRY_LIMIT`` - Set a maximum number of retries after which additional calls to ``onError`` will throw the most recently seen error code. Valid parameter values are ``[-1, INT_MAX]``. If set to -1, will disable the retry limit. Like all transaction options, the retry limit must be reset after a call to ``onError``. This behavior allows the user to make the retry limit dynamic.
|
||||
|
||||
|
|
|
|||
|
|
@ -257,7 +257,7 @@ Contains default parameters for all fdbserver processes on this machine. These s
|
|||
* ``maxlogssize``: Delete the oldest log file when the total size of all log files exceeds the specified size. If set to 0B, old log files will not be deleted. The default value is 100MiB.
|
||||
* ``class``: Process class specifying the roles that will be taken in the cluster. Recommended options are ``storage``, ``transaction``, ``stateless``. See :ref:`guidelines-process-class-config` for process class config recommendations.
|
||||
* ``memory``: Maximum memory used by the process. The default value is 8GiB. When specified without a unit, MiB is assumed. This parameter does not change the memory allocation of the program. Rather, it sets a hard limit beyond which the process will kill itself and be restarted. The default value of 8GiB is double the intended memory usage in the default configuration (providing an emergency buffer to deal with memory leaks or similar problems). It is *not* recommended to decrease the value of this parameter below its default value. It may be *increased* if you wish to allocate a very large amount of storage engine memory or cache. In particular, when the ``storage_memory`` parameter is increased, the ``memory`` parameter should be increased by an equal amount.
|
||||
* ``storage_memory``: Maximum memory used for data storage. This paramenter is used *only* with memory storage engine, not the ssd storage engine. The default value is 1GiB. When specified without a unit, MB is assumed. Clusters will be restricted to using this amount of memory per process for purposes of data storage. Memory overhead associated with storing the data is counted against this total. If you increase the ``storage_memory``, you should also increase the ``memory`` parameter by the same amount.
|
||||
* ``storage_memory``: Maximum memory used for data storage. This parameter is used *only* with memory storage engine, not the ssd storage engine. The default value is 1GiB. When specified without a unit, MB is assumed. Clusters will be restricted to using this amount of memory per process for purposes of data storage. Memory overhead associated with storing the data is counted against this total. If you increase the ``storage_memory``, you should also increase the ``memory`` parameter by the same amount.
|
||||
* ``locality_machineid``: Machine identifier key. All processes on a machine should share a unique id. By default, processes on a machine determine a unique id to share. This does not generally need to be set.
|
||||
* ``locality_zoneid``: Zone identifier key. Processes that share a zone id are considered non-unique for the purposes of data replication. If unset, defaults to machine id.
|
||||
* ``locality_dcid``: Data center identifier key. All processes physically located in a data center should share the id. No default value. If you are depending on data center based replication this must be set on all processes.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Fixes
|
|||
Fixes
|
||||
-----
|
||||
|
||||
* Expiring a backup could cause the fdbbackup process to hang indefinately. <rdar://problem/39382121>
|
||||
* Expiring a backup could cause the fdbbackup process to hang indefinitely. <rdar://problem/39382121>
|
||||
|
||||
5.1.5
|
||||
=====
|
||||
|
|
@ -103,7 +103,7 @@ Features
|
|||
* The behavior of atomic "and" and "min" operations has changed when the key doesn't exist in the database. If the key is not present, then an "and" or "min" is now equivalent to a set. <rdar://problem/29255441>
|
||||
* Exception messages are more descriptive. <rdar://problem/33665340>
|
||||
* Clients can view a sample of committed mutations. <rdar://problem/33324935>
|
||||
* When switching to a DR cluster, the commit verisons on that cluster will be higher than the versions on the primary cluster. <rdar://problem/33572665>
|
||||
* When switching to a DR cluster, the commit versions on that cluster will be higher than the versions on the primary cluster. <rdar://problem/33572665>
|
||||
* Added a read-only lock aware transaction option. <rdar://problem/34579176>
|
||||
* Automatically suppress trace log events which occur too frequently. <rdar://problem/33764208>
|
||||
* Added a new ``multi_dc`` replication mode designed for cross data center deployments. <rdar://problem/36489132>
|
||||
|
|
@ -122,7 +122,7 @@ Performance
|
|||
* Excluded servers no longer take on stateless roles. <rdar://problem/27110802>
|
||||
* Stateless roles will be proactively moved off of excluded processes. <rdar://problem/27110802> <rdar://problem/35155044>
|
||||
* Dramatically improved restore speeds of large disk queue files. <rdar://problem/35567320>
|
||||
* Clients get key location information directly from the proxies, sigificantly reducing the latency of worst case read patterns. <rdar://problem/35953920>
|
||||
* Clients get key location information directly from the proxies, significantly reducing the latency of worst case read patterns. <rdar://problem/35953920>
|
||||
* Reduced the amount of work incompatible clients generate for coordinators and the cluster controller. In particular, this reduces the load on the cluster caused by using the multi-version client. <rdar://problem/30897631>
|
||||
* Pop partially recovered mutations from the transaction log to save disk space after multiple successive recoveries. <rdar://problem/33755270>
|
||||
* Stopped using network checksums when also using TLS. <rdar://problem/32157852>
|
||||
|
|
@ -136,7 +136,7 @@ Fixes
|
|||
* Exclude considered the free space of non-storage processes when determining if an exclude was safe.
|
||||
* ``fdbmonitor`` failed to start processes after fork failure. <rdar://problem/34743257>
|
||||
* ``fdbmonitor`` will only stop processes when the configuration file is deleted if ``kill_on_configuration_change`` is set. <rdar://problem/35497412>
|
||||
* The data distribution algorithm would hang indefinately when asked to build storage teams with more than three servers.
|
||||
* The data distribution algorithm would hang indefinitely when asked to build storage teams with more than three servers.
|
||||
* Mutations from a restore could continue to be applied for a very short amount of time after a restore was successfully aborted.
|
||||
|
||||
Extremely Rare Bug Fixes
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ We have a number of customers, ranging from network analytics providers to VoIP/
|
|||
Time-series Data and FoundationDB
|
||||
=================================
|
||||
|
||||
If you only have a few fields to store per database record, it’s pretty simple to picture what a time-oriented record would look like. If you were tracking analytics for a website, you might have a few fields, such as a website identifer, a page identfier, and a browser type. That’s pretty simple to picture fitting into a defined, relational-database table that looks like this:
|
||||
If you only have a few fields to store per database record, it’s pretty simple to picture what a time-oriented record would look like. If you were tracking analytics for a website, you might have a few fields, such as a website identifier, a page identifier, and a browser type. That’s pretty simple to picture fitting into a defined, relational-database table that looks like this:
|
||||
|
||||
============= ========== ======= ==========
|
||||
Timestamp website_ID page_ID browser_ID
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ Command-line Option Client Option Environment Variable Purpo
|
|||
|
||||
The value for each setting can be specified in more than one way. The actual valued used is determined in the following order:
|
||||
|
||||
1. An explicity specified value as a command-line option or client option, if one is given;
|
||||
1. An explicitly specified value as a command-line option or client option, if one is given;
|
||||
2. The value of the environment variable, if one has been set;
|
||||
3. The default value
|
||||
|
||||
|
|
@ -194,7 +194,7 @@ Setting Result
|
|||
Adding verification requirements
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Requirements can be placed on the fields of the Issuer and Subject DNs in the peer's own certificate. These reqirements take the form of a comma-separated list of conditions. Each condition takes the form of ``field=value``. Only certain fields from a DN can be matched against.
|
||||
Requirements can be placed on the fields of the Issuer and Subject DNs in the peer's own certificate. These requirements take the form of a comma-separated list of conditions. Each condition takes the form of ``field=value``. Only certain fields from a DN can be matched against.
|
||||
|
||||
====== ===================
|
||||
Field Well known name
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ public:
|
|||
}
|
||||
|
||||
private:
|
||||
// Calculate an "average" of the metrics replies that we received. Penalize teams from which we did not receieve all replies.
|
||||
// Calculate an "average" of the metrics replies that we received. Penalize teams from which we did not receive all replies.
|
||||
int64_t getLoadAverage() {
|
||||
int64_t bytesSum = 0;
|
||||
int added = 0;
|
||||
|
|
@ -2072,7 +2072,7 @@ ACTOR Future<Void> popOldTags( Database cx, Reference<ILogSystem> logSystem, Ver
|
|||
tags.push_back(decodeServerTagValue( kv.value ));
|
||||
}
|
||||
|
||||
//FIXME: we have to check the old locality indefinately, because we can never be sure when pops have succeeded, we can remove this code when we no longer need to support upgrades from 5.X to 6.0
|
||||
//FIXME: we have to check the old locality indefinitely, because we can never be sure when pops have succeeded, we can remove this code when we no longer need to support upgrades from 5.X to 6.0
|
||||
popActors.push_back(popOldTags(&tr, logSystem, recoveryCommitVersion, tagLocalityUpgraded, tags));
|
||||
for(auto& kv : fTagLocalities.get()) {
|
||||
popActors.push_back(popOldTags(&tr, logSystem, recoveryCommitVersion, decodeTagLocalityListValue(kv.value), tags));
|
||||
|
|
|
|||
|
|
@ -167,7 +167,7 @@
|
|||
** level of recursion for each term. A stack overflow can result
|
||||
** if the number of terms is too large. In practice, most SQL
|
||||
** never has more than 3 or 4 terms. Use a value of 0 to disable
|
||||
** any limit on the number of terms in a compount SELECT.
|
||||
** any limit on the number of terms in a compound SELECT.
|
||||
*/
|
||||
#ifndef SQLITE_MAX_COMPOUND_SELECT
|
||||
# define SQLITE_MAX_COMPOUND_SELECT 500
|
||||
|
|
@ -18242,7 +18242,7 @@ static int unixLock(sqlite3_file *id, int eFileLock){
|
|||
|
||||
/* Make sure the locking sequence is correct.
|
||||
** (1) We never move from unlocked to anything higher than shared lock.
|
||||
** (2) SQLite never explicitly requests a pendig lock.
|
||||
** (2) SQLite never explicitly requests a pending lock.
|
||||
** (3) A shared lock is always held when a reserve lock is requested.
|
||||
*/
|
||||
assert( pFile->eFileLock!=NO_LOCK || eFileLock==SHARED_LOCK );
|
||||
|
|
@ -19491,7 +19491,7 @@ static int afpLock(sqlite3_file *id, int eFileLock){
|
|||
|
||||
/* Make sure the locking sequence is correct
|
||||
** (1) We never move from unlocked to anything higher than shared lock.
|
||||
** (2) SQLite never explicitly requests a pendig lock.
|
||||
** (2) SQLite never explicitly requests a pending lock.
|
||||
** (3) A shared lock is always held when a reserve lock is requested.
|
||||
*/
|
||||
assert( pFile->eFileLock!=NO_LOCK || eFileLock==SHARED_LOCK );
|
||||
|
|
@ -22475,7 +22475,7 @@ static int unixGetLastError(sqlite3_vfs *NotUsed, int NotUsed2, char *NotUsed3){
|
|||
** setting the environment variable SQLITE_FORCE_PROXY_LOCKING to 1 will
|
||||
** force proxy locking to be used for every database file opened, and 0
|
||||
** will force automatic proxy locking to be disabled for all database
|
||||
** files (explicity calling the SQLITE_SET_LOCKPROXYFILE pragma or
|
||||
** files (explicitly calling the SQLITE_SET_LOCKPROXYFILE pragma or
|
||||
** sqlite_file_control API is not affected by SQLITE_FORCE_PROXY_LOCKING).
|
||||
*/
|
||||
|
||||
|
|
@ -67194,7 +67194,7 @@ static void zeroblobFunc(
|
|||
/*
|
||||
** The replace() function. Three arguments are all strings: call
|
||||
** them A, B, and C. The result is also a string which is derived
|
||||
** from A by replacing every occurance of B with C. The match
|
||||
** from A by replacing every occurrence of B with C. The match
|
||||
** must be exact. Collating sequences are not used.
|
||||
*/
|
||||
static void replaceFunc(
|
||||
|
|
@ -90931,7 +90931,7 @@ SQLITE_PRIVATE int sqlite3KeywordCode(const unsigned char *z, int n){
|
|||
** end result.
|
||||
**
|
||||
** Ticket #1066. the SQL standard does not allow '$' in the
|
||||
** middle of identfiers. But many SQL implementations do.
|
||||
** middle of identifiers. But many SQL implementations do.
|
||||
** SQLite will allow '$' in identifiers for compatibility.
|
||||
** But the feature is undocumented.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -355,7 +355,7 @@ template <> inline void FieldHeader<Standalone<StringRef>>::update(Standalone<St
|
|||
// data block or to read all field values from a metric value block. This usage pattern enables enables
|
||||
// encoding and decoding values as deltas from previous values.
|
||||
//
|
||||
// The default implemenation works for ints and writes delta from the previous value.
|
||||
// The default implementation works for ints and writes delta from the previous value.
|
||||
template <typename T>
|
||||
struct FieldValueBlockEncoding {
|
||||
FieldValueBlockEncoding() : prev(0) {}
|
||||
|
|
@ -1156,7 +1156,7 @@ struct FieldValueBlockEncoding<TimeAndValue<T>> {
|
|||
FieldValueBlockEncoding<T> value_encoding;
|
||||
};
|
||||
|
||||
// ValueBlock encoder/decoder specialization for continous bool metrics because they are encoded
|
||||
// ValueBlock encoder/decoder specialization for continuous bool metrics because they are encoded
|
||||
// more efficiently than encoding the time and bool types separately.
|
||||
// Instead, time and value are combined to a single value (time delta << 1) + (value ? 1 : 0) and then
|
||||
// that value is encoded as a delta.
|
||||
|
|
|
|||
|
|
@ -1191,7 +1191,7 @@ int GetCPU();
|
|||
// family of functions as standardized in POSIX.1-2001.
|
||||
//
|
||||
// Note: While Apple provides <semaphore.h> for both iOS and macOS, it is
|
||||
// explicity deprecated and will cause build failures if enabled for those
|
||||
// explicitly deprecated and will cause build failures if enabled for those
|
||||
// platforms. We side-step the issue by not defining it here for Apple
|
||||
// platforms.
|
||||
#ifdef ABSL_HAVE_SEMAPHORE_H
|
||||
|
|
@ -1250,7 +1250,7 @@ int GetCPU();
|
|||
|
||||
// ABSL_HAVE_STD_ANY
|
||||
//
|
||||
// Checks whether C++17 std::any is availble by checking whether <any> exists.
|
||||
// Checks whether C++17 std::any is available by checking whether <any> exists.
|
||||
#ifdef ABSL_HAVE_STD_ANY
|
||||
#error "ABSL_HAVE_STD_ANY cannot be directly set."
|
||||
#endif
|
||||
|
|
|
|||
Loading…
Reference in New Issue