forked from lei.chen/myxce
Adds an explicit case WAL_CONFIG_MARKER to apply_committed_entry, replacing its no-op treatment, that forces a checkpoint at exactly the marker's own (term, lsn) via two new helpers: persist_checkpoint_write_locked(p, checkpoint_lsn) -- the checkpoint core (pin lsn, scan config ref, write_snapshot, trim, rotate) taking an explicit LSN and never acquiring apply_pump_lock itself persist_checkpoint_marker_triggered(p, lsn) -- shares the existing checkpoint_in_progress CAS guard, calls the above with the marker's own lsn This fixes two hazards design.md's "call persist_checkpoint() directly" text didn't account for: (1) apply_committed_entry's live-pump caller (persist_apply_pump_run, used by both primary and standby online-apply) already holds apply_pump_lock across the dispatch call -- a direct persist_checkpoint() call would self-deadlock on that mutex; (2) last_applied_lsn/replay position only advance AFTER apply_committed_entry returns at both call sites, so pinning checkpoint_lsn from last_applied_lsn inside the marker case would label the checkpoint with the previous entry's LSN, not the marker's own -- fixed by threading the marker's own lsn parameter through explicitly. A -EBUSY outcome (a concurrent periodic checkpoint mid-flight) is logged at TRACE and treated as expected/self-resolving, never retried. The new case has no effect on entity interpretation/re-homing (Req 1.8). New test_upgrade_snapshot_apply.c drives WAL_CONFIG_MARKER through the REAL production call paths (persist_apply_pump_run and boot replay via persist_recover), not a bare apply_committed_entry() call, so the fix is actually proven against the lock-holding context rather than assumed. Also fixes a genuine regression in test_config_repl.c surfaced by WAL_CONFIG_MARKER apply having a real side effect for the first time (bug-1466): an fsync-worker-thread race (t42_wait_applied polling helper, mirrors test_apply_pump.c's tap_wait_applied) and one test call site trusting an unreliable raft-derived LSN. Surfaces (but does not fix, out of this spec's boundary) a pre-existing ha-term-safety/raft-log-replication gap: persist_write_checkpoint_marker bypasses ha_primary_log_append, breaking its documented current_lsn==log_len+1 invariant once a checkpoint interleaves with primary appends -- log_len feeds real RequestVote freshness comparisons, not advisory-only as first assumed; severity corrected in bug-1466. Task 5 of 19. Requirements: 1.1, 1.5, 1.8, 4.4, 5.2, 5.3 |
||
|---|---|---|
| .. | ||
| hooks | ||
| anatomy.md | ||
| buglog.json | ||
| cerebrum.md | ||
| config.json | ||
| cron-manifest.json | ||
| cron-state.json | ||
| daemon.log | ||
| designqc-report.json | ||
| identity.md | ||
| memory.md | ||
| OPENWOLF.md | ||
| reframe-frameworks.md | ||
| suggestions.json | ||
| token-ledger.json | ||