Elementary full text search implementation - #630
Closed
jokokko wants to merge 1 commit into
Closed
Conversation
Member
|
Sorry I've been so slow getting around to this one. I'd be happy to take this one in today. I do think we need to add some additional tests for the database object lifecycle (clean out the DB, see it get reestablished, different schema auto-creation rights). What else do you think needs to happen to get this production ready? And docs, but that's no big deal. |
Collaborator
Author
|
Yeah, the things you mention need to be there... I don't know if the UsingVector is the most elegant way to go, but on the other hand it gives explicit control over naming (maybe omitting that could default to reflecting over the member name and using that as part of the name). I'll hope to find the time to refine this PR soon. |
Member
|
I'm closing because there's no activity here. I think the consensus seems to be to just wait for Postgresql 10. |
|
Now? I could really use this! |
jeremydmiller
added a commit
that referenced
this pull request
Aug 4, 2026
#630 (marten#5167), the companion to #5186. Two changes: The IEventDatabase batched extended-progression contract now REQUIRES one row per transaction rather than asking for "as few round-trips as the store can manage". The old wording said nothing about transaction scope, which is what made Marten's single `UPDATE ... FROM unnest(...)` a reasonable reading of it -- and that statement holds a row lock on every shard in the batch until it commits. Polecat needs the corrected contract before it implements the batched overload. ExtendedProgressionWriter now flushes each batch ordered by shard name. With one row per transaction a single writer never holds more than one row lock, but the tracker is per-database and shared and BuildProjectionDaemonAsync is not cached, so two writers can race over the same rows; the pending dictionary's enumeration order is an implementation detail rather than an agreement between them. Marten's own fix (#5186) does not depend on this bump -- the convoy was in Marten's SQL. What this adds is the cross-writer deadlock hazard being closed and the contract being stated for the next implementer. DaemonTests 300/300 and CoreTests jasper_fx_mechanics 18/18 green on net9.0. Claude-Session: https://claude.ai/code/session_017CTtw2kVRSZKp1p5RTxgAy Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
jeremydmiller
added a commit
that referenced
this pull request
Aug 4, 2026
#631 — a status transition published while the shard has NO progression row to decorate landed nowhere, because every store's extended-progression write is update-only. That describes every fresh shard's Started: the agent starts before its first batch commits. With the periodic beat off by default since #622 there was no later write to correct it, so agent_status and heartbeat stayed NULL for the entire life of a healthy agent. The shard is now remembered and written again on the first publication carrying a committed sequence, which is proof the row exists. The #630 follow-up: a duplicate ExtendedProgressionWriter on one database now logs a warning. It used to announce itself as lock contention -- two writers issuing multi-row UPDATEs over the same rows in plan-dependent order is a deadlock hazard. The one-row-per-transaction rewrite in #5186 made a duplicate harmless to correctness and therefore SILENT, while it still means two projection daemons are started for one database. Reported and not refused: the duplicate writer is the symptom, not the bug. Version bumped to 9.22.4 for the release. DaemonTests 301/301 green on net9.0. Claude-Session: https://claude.ai/code/session_017CTtw2kVRSZKp1p5RTxgAy Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
3 participants
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.
Could this serve as a basis for #39?