Visitar URL original
The sorted index build is refused whenever ANY transaction on the thread holds a write, even one unrelated to the indexed type · Issue #10466 · ArcadeData/arcadedb · GitHub
Skip to content

The sorted index build is refused whenever ANY transaction on the thread holds a write, even one unrelated to the indexed type #10466

Closed

Description

@robfrank

Follow-up from #10450.

#10450 narrowed the decision of whether an index build joins the caller's transaction to "has the caller written to the buckets this build scans" (IndexBuilder.callerTransactionHasChangesIn). The sorted build has its own, broader guard: TypeIndexBuilder.sortedBuildRefusal() refuses it (and isSortedBuildChosenFor silently falls back to the record-at-a-time build) when anyCallerTransactionHasChanges() is true, i.e. when any transaction stacked on the thread holds any write at all.

So BEGIN; INSERT INTO Unrelated ...; CREATE INDEX ON Big (id) UNIQUE; COMMIT over a large committed Big loses the sorted build (#10334, #10267), and a UNIQUE index pays the quadratic record-at-a-time build again, even though the sorted build only needs the indexed buckets to be free of pending writes.

Entry point: TypeIndexBuilder.sortedBuildRefusal() / isSortedBuildChosenFor().

Why it was out of scope for #10450: the sorted build sets the whole transaction stack aside (CommittedReadScope) and writes its pages outside any transaction. Narrowing its guard needs the same per-bucket test, applied to every transaction in the stack (not only the innermost one), plus an argument that writing index pages outside a transaction while an unrelated outer transaction holds pages is safe. That deserves its own change and tests.

Activity

  1. added this to the 26.11.1 milestone on Oct 20, 2026
  2. self-assigned this
    on Oct 20, 2026
  3. added a commit that references this issue on Oct 21, 2026
  4. robfrank commented on Oct 21, 2026

    @robfrank
    CollaboratorAuthor

    Fixed in #10475. The sorted index build was refused whenever any open transaction held any write, so BEGIN; INSERT INTO Unrelated ...; CREATE INDEX ON Big (id) UNIQUE; COMMIT fell back to the much slower record-at-a-time build. The build is now refused only when some open transaction (at any nesting level) wrote to the buckets the index scans, including sub-type buckets. Writes to the indexed type, including updates, deletes and sub-type inserts, are still refused. The fix is complete.


    ❤️ Thanks for helping make ArcadeDB better! ArcadeDB is free and open source, sustained by its community. If it's useful to you or your company, please consider becoming a sponsor to keep development going.

  5. removed
    in progressThe team is actively working on this issue
    on Oct 21, 2026
  6. added 2 commits that reference this issue on Oct 21, 2026
  7. added 2 commits that reference this issue on Nov 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

engineCore engine: document/schema APIperformanceseverity:minorCosmetic, documentation, edge case, or a workaround exists

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions