Skip to content

A write does not queue a vector index build while one for the same table and dims is running - #44

Merged
gedaiu merged 1 commit into
re-devfrom
fix/one-index-build-at-a-time
Oct 27, 2026
Merged

gedaiu merged 1 commit into
re-devfrom
fix/one-index-build-at-a-time

Conversation

@gedaiu

@gedaiu gedaiu commented Oct 27, 2026

Copy link
Copy Markdown

Since re.25 (#43), a 3072-dim base gets index builds, and a build of 464k entity profiles runs for over an hour. vector_index::request skipped a duplicate only while one was queued. Once a worker claimed the build, every write queued another. Each one took a worker slot and polled the build's advisory lock until the first finished: in production, 43 connections were waiting within 15 minutes, eating into the 64 job slots that ingestion needs.

request now uses the existing jobs::enqueue_unless_pending with no delay, so a queued or running build blocks a new one. That function's contract is that the job takes in what changed while it ran, and CREATE INDEX CONCURRENTLY does, because rows written during the build are indexed. A build left running by a dead process is requeued by the worker on start, so it cannot block forever.

the_first_write_of_a_dimension_queues_one_build now marks the queued build running and checks that another write queues nothing. It fails without the change.

🤖 Generated with Claude Code

…ble and dims is running

Signed-off-by: Bogdan Szabo <bogdan@re-cinq.com>
@gedaiu
gedaiu merged commit dbb2e5a into re-dev Oct 27, 2026
6 checks passed
gedaiu added a commit to re-cinq/lore that referenced this pull request Oct 27, 2026
Pins `0.1.0-re.26` (`sha256:e02877d8…`), which adds re-cinq/utopia#44 on
top of re.25.

With re.25, every write queued another index build while one was already
running. Each queued build took a worker slot and waited on the build
lock: 53 slots out of 64 in production within about 30 minutes, which
starves ingestion. re.26 queues no new build while one for the same
table and dims is queued or running.

No new migration and no database restart. Only the app pod is recreated,
and it requeues the waiting jobs on start; those then exit as soon as
their index exists.

Related: re-cinq/utopia#44, #3727

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant