You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@kvrocks.apache.org by GitBox <gi...@apache.org> on 2026/08/30 15:29:18 UTC

[GH] (kvrocks/pr/flushwal-command): Workflow run "CI" failed!

The GitHub Actions job "CI" on kvrocks.git/pr/flushwal-command has failed.
Run started by GitHub user pipinstall1 (triggered by pipinstall1).

Head commit for run:
8f9aa876006c5ac15f72be4e02a3e2a9d5fb7efb / refactor-bot <re...@users.noreply.github.com>
feat(command): add FLUSHWAL to flush and fsync the RocksDB WAL

Expose rocksdb::DB::FlushWAL(/*sync=*/true) as a FLUSHWAL command. With
rocksdb.write_options.sync=no, writes are appended to the WAL buffer per
command but only made durable by background flushes; nothing in the
command surface lets a client force that boundary. FLUSHWAL flushes the
WAL buffer to the file and fsyncs it, making every write accepted before
the call durable across a process or machine crash.

Motivation: group-commit durability. An application tier running with
sync=no can append fast, hold acks, and issue one FLUSHWAL per T ms (or
per N writes), then release every ack accepted before the flush -
ack=fsynced semantics at a fraction of the per-write fsync cost. On a
disk with an ~12 ms fsync floor, a Lua append script doing 4 writes per
call moves from ~20 appends/s (sync=yes, one fsync per write batch) to
~2,400 appends/s with a 5 ms flush window, with the loss window on power
failure bounded by the flush interval (process crash alone loses
nothing: the WAL is still written per command).

The command rejects under rocksdb.write_options.disable_wal (there is no
WAL to flush) and surfaces any RocksDB error. It performs no keyspace
write and needs no exclusivity; registered read-only admin to match the
other storage-maintenance commands.

Co-Authored-By: Claude Fable 5 <no...@anthropic.com>

Report URL: https://github.com/apache/kvrocks/actions/runs/33319606821

With regards,
GitHub Actions via GitBox