Repository navigation
fix(storage): keep claim tombstone checks correlated (0.6) - #715
Conversation
hardbyte
added
the
full-ci
Claude
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
 |
A claim marks each candidate row with EXISTS over ready_tombstones. For a small batch PostgreSQL could plan that as a hashed subplan, reading the slot's whole tombstone partition on every claim although the lookup index exists. OFFSET 0 in the subquery keeps it one index probe per candidate row. The installer writes the fenced check into new substrates. The correlated_claim_tombstones schema patch rewrites claim_ready_runtime in every installed queue-storage schema from its own definition, so signature, owner, privileges and settings are unchanged. Function replacement only; no table lock. 0.6 port of #713. Co-authored-by: Wallace99 <5481339+Wallace99@users.noreply.github.com>
4b89732 to
b817fbc
Compare
0.6 port of #713 by @Wallace99, fix-first on the 0.6 line per the branch policy in #383. #713 targets
mainwith migration v056; the 0.6 series cannot add a migration version, so this delivers the same fix as a repeatable schema patch. Forward-port tomainin the bundled port.Problem
A claim marks each candidate row with
EXISTSoverready_tombstones. For a small batch PostgreSQL can plan thatEXISTSas a hashed subplan, which reads the slot's whole tombstone partition on every claim although the lookup index exists. In the regression test a 32-row claim sequentially reads 10,000 tombstone rows on unpatched 0.6 functions.Change
OFFSET 0in both tombstone subqueries ofclaim_ready_runtimekeeps each check correlated: one index probe per candidate row. Results are unchanged.correlated_claim_tombstonesrewritesclaim_ready_runtimein every installed queue-storage schema from the function's own definition (pg_get_functiondef), so signature, owner, privileges and settings are unchanged. A function that already carries the fence does not match and is left alone.Differences from #713
R__correlated_claim_tombstones.sql, notV56.claim_ready_runtimeand a partitionedready_tombstones) and takes the per-schema install advisory lock.claim_ready_runtime; there are no per-slotclaim_ready_slot_<n>functions. The patch still matches that name pattern, which is harmless here.Compatibility
R__correlated_claim_tombstones.sqlafterV40, as the owner of the claim functions.Tests
awa-model/tests/claim_tombstone_plan_test.rs, ported from fix(storage): keep claim tombstone checks correlated #713: legacy and receipt modes, custom and generic plans, tombstone hits and misses on real 32-row claims. It restores the released function bodies, checks the probe names each unfenced function, applies the patch, checks replay leaves the body unchanged, and asserts zero sequentially scanned tombstone rows. Passes on PG18. Without applying the patch it fails with 10,000 rows scanned.patch_upgrade_rehearsal_testexpectations include the new patch; that test needs released binaries and runs in CI.awa-modelmigration lib tests,migrate_patch_cli_testandruntime_control_testpass.migration_testwas still running when this was opened.cargo fmtand clippy (awa-model,awa,awa-cli, all targets and features) pass.Docs
docs/migrations.md: the new repeatable patch.Generated by Claude Code