Repository navigation
Preserve reader count metadata during concurrent writes - #74
Merged
Merged
Conversation
Codex Review SummaryThis 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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Readers created while a legacy writer holds its gate could lose exact committed row counts and repeatedly scan the table for
COUNT(*), including after publication finished. Capture committed catalog metadata before legacy write admission and retry a safe capture after publication, retaining immutable state for readers already open. Keep the WAL concurrency fix, publication barriers, and conservative fallback after failed synchronization intact.Update v4.6.6 release notes and the Unreleased changelog summary to include this fix.
Type of Change
Related Issues
Follow-up to #73 and failed release qualification run https://github.com/MaxAkbar/CSharpDB/actions/runs/38185104713. No issue closure.
Testing
dotnet build CSharpDB.slnx(Release, clean overlay: zero warnings/errors)All nine new regression tests pass with the fix; six fail against unchanged merged source 99ad896. Full Windows suite: 8,519 passed, zero failed, four existing optional SQL Server/MySQL/Access live-fixture skips across 27 modules. Documentation validation passed.
The unchanged tuned direct-client release workload improved in all three local before/after pairs: 14,577–18,143 to 310,953–329,003 reads/sec; P95 4.659–5.950 ms to 0.054–0.056 ms. Binary manifests confirmed only the engine assembly differed. A separate instrumented diagnostic recorded both reader and writer work and improved both in all six final continuous/paced writer pairs. These local results do not replace hosted release qualification or establish identical hosted interleavings.
Checklist
Notes for Reviewers
Reader creation never waits for the engine writer/shared-state gates. Writer capture takes the reader catalog monitor and tries the shared-state gate without waiting; acquired gates and temporary snapshot leases are released in
finally. Failed native/legacy synchronization still forces snapshot-backed reads. Databases with prior readers pay catalog capture work at legacy write admission; large-catalog/page-map overhead has not been separately benchmarked.No workload thresholds, benchmark settings, database formats, or public APIs changed. Linux/macOS validation, hosted performance qualification, and release packaging remain required before publishing v4.6.6.