rocksdb

Summary: Fixes three unrelated nightly/CI failures. Makefile: 'make build_folly' was tripping the build-signature change check, causing the folly-flavored jobs (e.g. nightly clang-21 ASAN+UBSAN+folly, which runs 'make build_folly' then 'USE_FOLLY=1 ... make check') to abort with 'Build parameters changed since the last build'. build_folly only builds the external folly library under third-party/folly and never compiles RocksDB objects into OBJ_DIR, so it should not record or check a build signature; add it to BUILD_SIG_NONBUILD_GOALS alongside checkout_folly. util/rate_limiter_test.cc: RateLimiterTest.Rate's minimum-rate assertion is timing-sensitive and flakes on the small/loaded ARM CI runners, which (unlike x86_64) can't reliably sustain the target rate. Extend the existing CI exemption with an ARM-only GITHUB_ACTIONS branch, preserving the check on x86_64. tools/ldb_test.py: the list_live_files_metadata output includes the full DB path, and the unescaped-dot regex '\d+.sst' could match a sst run inside the random tempfile.mkdtemp suffix (drawn from [a-z0-9_]) that precedes the real filename, collapsing testMap to a single bogus key such as '8asst'. Require a literal '.sst'; temp-dir characters can never contain a dot, so only the real filename matches. Test Plan: build_folly: confirmed 'make build_folly' no longer writes .build_signature and that BUILD_SIG_DO_BUILD resolves empty for that goal. rate_limiter_test: confirmed via the C preprocessor that x86_64 keeps the SANDCASTLE-only exemption while aarch64 selects the new GITHUB_ACTIONS branch. ldb_test: reproduced the collapse with a poisoned temp suffix (produces {'8asst': ['0', 'mycol2']}) and confirmed the escaped-dot regex yields the correct 4-entry map.

Context The C API lacks a SetDBOptions wrapper, so callers using the C bindings cannot dynamically reconfigure DB-level options at runtime without dropping down to the C++ API. Changes Add to the C API as a wrapper around Adds new tests in covering both valid and invalid option updates

Summary: took its "already aligned" fast path when the request offset and length were sector-aligned, forwarding the caller's (including its pointer) straight to the FileSystem. A null trivially satisfied the alignment check (), so when a caller submitted an aligned request with and an out-parameter for the reader to allocate into, the null buffer was submitted to the async read. For direct IO with io_uring this becomes a null base, which the kernel rejects with (surfaced as ). This is exactly how submits MultiScan async reads for plain direct IO (, provided), so the failure manifested intermittently as iterator divergence ("Iterator diverged from control iterator") in crash tests with . It is intermittent because it only triggers when the coalesced read's offset and length both happen to be sector-aligned. Task T267030385. The fix excludes the aligned fast path when the caller provided no but did provide an , forcing the allocating path so a valid backing buffer is always handed to the async read. This matches the existing behavior of the synchronous , which already guards its aligned fast path with . Differential Revision: D110361301