Skip to content

core/storage: Some fallible allocations for sqlite3_ondisk.rs#7398

Open
pedrocarlo wants to merge 2 commits into
tursodatabase:mainfrom
pedrocarlo:on-disk-alloc
Open

core/storage: Some fallible allocations for sqlite3_ondisk.rs#7398
pedrocarlo wants to merge 2 commits into
tursodatabase:mainfrom
pedrocarlo:on-disk-alloc

Conversation

@pedrocarlo

Copy link
Copy Markdown
Collaborator

Description

Adds some more fallible allocations in sqlite3_ondisk.rs

Motivation and context

Fallible allocations

Description of AI Usage

Not much, just to verify my work a bit

@pedrocarlo pedrocarlo changed the title On disk alloc some fallible allocations for sqlite3_ondisk.rs Jun 5, 2026
@penberg penberg changed the title some fallible allocations for sqlite3_ondisk.rs core/storage: Some fallible allocations for sqlite3_ondisk.rs Jun 6, 2026
if run_start_id.is_none() {
run_start_id = Some(*id);
}
// Most likely Preallocated enough to not use `try_push.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why "Most likely"?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is mainly me being skeptical about the let mut run_bufs = fail_run_if_err!(Vec::try_with_capacity_ext(EST_BUFF_CAPACITY)); preallocation. It seems to be an estimated capacity and I was trying to avoid a try_push call here which is slower. We could IMO, force a max amount of pages we can have in a single vectored read, which would make the preallocation exact. But I did not do this here, as this PR is supposed to be more mechanical in nature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants