CommitDebug trace events are useful for measuring, in detail, the time spent in
the various parts of a single transaction. Like all log events, they have a time
associated with them. This time comes for now(), which in a real fdb system is
only updated in the run loop. This renders the timestamps inaccurate in certain
CPU bound sections which don't have a wait, e.g. in the resolver.
We want to preserve the current behavior in simulation, where the timestamps are
artificial, deterministic between runs, and only updated in the run loop.
In a real system, we prefer to use a real clock so we can use the difference
between two trace events in the logs as a measurement of elapsed time.
This does not modify the behavior of other parts of the system, which use the
cached now() for various purposes.
* client_config_tester: use a generic mechanism to set specific network options
* trace_initialize_on_setup option to initialize client traces on network setup without local IP address
* trace_initialize_on_setup: Addressing review comments
* Restore correct formatting
* trace_initialize_on_setup: Update go bindings
* Include PID for identification into trace file names by default
* Use the same naming pattern for trace files in all configurations
* Empty commit
In the HA configuration, it's possible the remote DC was killed 2 out of 3
machines, left not enough machines for a successful recovery. So this PR changes
to Reboot to avoid such excessive killings.
From one of nightly failure due to too many log lines, these are top 3:
60100 FastRestoreLoaderDispatchRequests
79655 FastRestoreGetVersionSize
93888 FastRestoreSplitMutation
Adds a prototype of new APIs to access the Blob Granule data:
fdb_future_readbg_get_descriptions
fdb_readbg_parse_snapshot_file
fdb_readbg_parse_delta_file
fdb_result_get_bg_mutations_array
The client first calls fdb_future_readbg_get_descriptions to get a high level description of granules, reads the files and then calls fdb_readbg_parse_snapshot_file and fdb_readbg_parse_delta_file to parse the snapshot and delta files, respectively. This allows the client to get a raw access to the blob granule data, and allows the client to process them in a way they wouldn't be efficiently able to when using previous blob granule read APIs.
We expect these APIs to evolve before a release.
---------
Co-authored-by: Josh Slocum <josh.slocum@snowflake.com>
The deltaFileData parameter was type StringRef[], this indirectly causes
issue #9206. By setting the incoming parameter type to be
std::vector<StringRef>, the issue might be fixed plus adding extra
memory safety.
Vaidas Gasiunas