Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Multi-process follow-ups after #221 (open lock): index fill under the lock, dictionary reload for readers, stale free-list head, ...

Open
  • Is something wrong?
#226 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
databases, distributed-systems

Research direction

Start with the open-lock path in WalSharedMemory.cs (EnterOpenLock, EnterOpenLockCore, ReleaseOpenLock), then StorageEngine.Dictionary.cs (GetDictionaryKey), StorageEngine.Memory.cs (.slots handling) and PageFile.cs (IsUnwrittenNewFile). Each numbered point needs either a fix or a documented decision, and the list is probably better split into separate issues. Multi-process locking and the free-list design need maintainer input before any code change.

Written by the indexing model from the issue text.

Description

triage

Non-blocking points found while reviewing #221 (open lock for multi-process create/open, #216). None of them is a regression that blocks #221; collected here so they don't get lost.

  1. Index migration and fill run under the open lock. MigrateLegacyDecimalIndexes and ApplyIndexBuilder (model-declared index fill, #175) run inside the DocumentCollection constructor / CreateCollection, so under EnterOpenLock(). While one process builds a large index, other processes' opens, new dictionary keys and first collection-file opens wait up to 60 s (WalSharedMemory.cs, open-lock timeout) and then throw TimeoutException. Either keep the fill out of the lock (fill unregistered, then register under the lock) or document it in roadmap/v5/MULTI_PROCESS_WAL.md.
  2. Readers don't see dictionary keys added by other processes. GetDictionaryKey (StorageEngine.Dictionary.cs) never reloads, so a process can't decode a key id another process added after it opened (it gets null). The new-key path in #221 reloads; the read path doesn't.
  3. Cost of a new key in multi-process mode. Each new key re-reads the whole dictionary and refreshes every open page file. That adds up for schemaless workloads with many distinct field names.
  4. Stale free-list head in a writer that doesn't take the open lock. RefreshAllocationState re-reads _firstFreePageId only under the open lock. If another process takes pages from the free list meanwhile, a writer can hand out a page from its stale head. Same root cause as the block-skip fix in #221 (60a9c9f), which covers only appended pages.
  5. Leaked pages. Each skip past another process's block abandons the rest of this engine's own block; those pages are never allocated until a compaction.
  6. .slots not reloaded under the open lock (StorageEngine.Memory.cs). With CollectionDataDirectory, two processes can give the same slot to different collections and overwrite each other's .slots. Predates #221.
  7. Encrypted files whose creator crashed. IsUnwrittenNewFile (PageFile.cs) skips encrypted files, so an encrypted database whose creator died before writing the header still can't be opened. (The zero-file re-initialisation in #221 also applies in single-process mode; worth a line in the release notes.)
  8. ReleaseOpenLock has no "held" flag, unlike the writer lock's _writerLockHeld. A release while another thread of the same engine still holds it (engine disposed mid-constructor) can leave the in-process semaphore or the macOS lock descriptor wrong.
  9. Small race: a collection file disposed by DropCollectionFile while EnterOpenLockCore iterates the files makes that call throw ObjectDisposedException.
  10. macOS sidecar: <shm>.open.lock stays on disk like the existing .lock; document it with the other sidecar files.
Dominant language
C#
Stars
66
Forks
6
Avg merge
1d 2h
Merged PRs (30d)
58

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EntglDb/BLite

All issues in EntglDb/BLite

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.