Skip to content

db/kv/membatchwithdb: restrict overlays to the pure-Go memStore backing - #22534

Draft
yperbasis wants to merge 1 commit into
mainfrom
yperbasis/membatch-memstore-only
Draft

db/kv/membatchwithdb: restrict overlays to the pure-Go memStore backing#22534
yperbasis wants to merge 1 commit into
mainfrom
yperbasis/membatch-memstore-only

Conversation

@yperbasis

Copy link
Copy Markdown
Member

Split out of #21293 (FcuBackgroundCommit groundwork).

Shared-tx overlay read views (MemoryMutation.NewReadView / NewTemporalReadView) are safe under a concurrent parent Close only on the pure-Go memStore backing, whose Rollback/Close are no-ops on the data — that is what lets a background-commit goroutine close the published overlay while RPC readers still iterate views. This PR makes the invariant structural instead of conventional:

  • MemoryMutation.memTx is typed *memStore (was kv.RwTx), so an overlay cannot be constructed on a backing whose Rollback invalidates cursors.
  • NewMemoryBatchMDBX (the MDBX-backed constructor, unused) is removed: its write tx pins the goroutine to an OS thread and its Rollback destroys the data under live read views — exactly the construction the invariant forbids.
  • The safe-close contract is documented once at newReadViewMut, with pointers from MemoryMutation.Rollback, SharedDomains.Close, and Filters.WithOverlay/WithTemporalOverlay (the read-view producers/consumers that rely on it).

Split out of #21293. Shared-tx read views are safe under a concurrent
parent Close only because memStore's Rollback/Close are no-ops on the
data; typing memTx as *memStore enforces that backing. Remove the unused
MDBX-backed constructor, whose write tx pins an OS thread and would
invalidate cursors mid-iteration.
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