dosync method (lines 126-134) treats batches specially with force=True — explore what happens to individual appends under batch or none sync modesDate: 2026-05-29
Time: 06:34
The observations provided cover the key code. Let me trace through the full sync behavior.
write-ahead-log/wal.py:append — See the full append method to confirm it calls dosync() without force and trace the complete write-then-sync sequencewrite-ahead-log/wal.py:_rotate — Rotation does unconditional fsync — this is the safety net that eventually persists data even in none modebatch-write-durability — Find the batch write method that uses force=True and verify whether it provides atomicity (all-or-nothing) or just durability (all-flushed)write-ahead-log/test_wal.py — Check whether tests exercise the durability gap: what happens if a crash occurs mid-batch in none modewrite-count-reset-semantics — Determine whether writecount should reset on any fsync (including forced) or only on batch-threshold syncs — potential bugbatch-mode-defers-fsync — In batch sync mode, individual appends do not fsync until writecount reaches batchsync_count (default 100), leaving up to N-1 records vulnerable to crash lossnone-mode-never-syncs-on-append — In none sync mode, dosync is a no-op for individual appends; data reaches disk only via rotation or explicit closeforce-true-bypasses-sync-mode — Passing force=True to dosync causes flush+fsync regardless of the configured sync mode, enabling group commit at batch boundariesrotation-always-fsyncs — The _rotate method unconditionally calls flush() and os.fsync() before closing the current file, providing a durability checkpoint even in none modebatch-write-count-not-reset-on-forced-sync — The writecount counter only resets when the batch threshold triggers a sync, not when a forced sync occurs, which may cause counter drift