forked from lei.chen/myxce
Rongsong Shen
1da26b043e
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 |
||
|---|---|---|
| .. | ||
| admin-config-tool | ||
| clusterconfig-schema-split | ||
| component-failover-adoption | ||
| config-upgrade-snapshot | ||
| controller-status | ||
| election-iomgr-refactor | ||
| ha-commit-barrier-rollout | ||
| ha-commit-durability | ||
| ha-commit-engine | ||
| ha-config-bootstrap | ||
| ha-consistency-invariants | ||
| ha-convergence-recovery | ||
| ha-elect-ctx-lifecycle | ||
| ha-entity-snapshots | ||
| ha-heartbeat-committed-propagation | ||
| ha-heartbeat-liveness | ||
| ha-peer-connection-reuse | ||
| ha-prevote | ||
| ha-repl-hardening | ||
| ha-single-leader-role | ||
| ha-term-safety | ||
| ha-wal-replication | ||
| job-array-single-wal-record | ||
| libxce-failover | ||
| raft-apply-decoupling | ||
| raft-commit-safety | ||
| raft-drive-async | ||
| raft-ha-core-safety | ||
| raft-library | ||
| raft-log-replication | ||
| raft-sim-conformance | ||
| resource-distribution-mapping | ||
| resval-id-decoupling | ||
| scheduler-controller-msg-gap | ||
| scheduler-framework | ||
| worker-join-refactor | ||
| xce-test-e2e-primitives | ||
| .gitignore | ||