Jun 2026
Checkpoint, Vacuum & Log Reclamation in CUBRID
Why archive logs stop being purged — and why it's checkpoint, not vacuum
A code-grounded walk through how CUBRID reclaims WAL archive logs, and the CBRD-26957 disk-full incident where archives grew monotonically under concurrent AUTO_INCREMENT load. Frames log retention as three independent horizons — REDO and UNDO on the LSA axis (owned by the fuzzy checkpoint), GC on the MVCCID axis (owned by vacuum) — that meet only at the archive-truncation MIN and at crash-recovery resume. Maps each to code: logpb_checkpoint releasing LOG_CS before the synchronous page flush, the redo point from the oldest unflushed dirty page, the checkpoint record carrying no MVCC state, the vacuum visibility gate (newest_mvccid vs oldest_visible), keep_from_log_pageid, and the MIN clamps in logpb_remove_archive_logs_exceed_limit. Closes on the incident: a hot db_serial page write-latched by ~120 workers starves the checkpoint's synchronous flush so it never completes and the syscrash horizon freezes at 0 — while vacuum, which flushes non-blocking, follows the log head normally. The sync-vs-async flush asymmetry is why it is checkpoint, not vacuum.
