Skip to content

colfetcher: don't use the cFetcher's allocator for other stuff#94674

Merged
craig[bot] merged 1 commit intocockroachdb:masterfrom
yuzefovich:clarify-cfetcher-allocator
Jan 4, 2023
Merged

colfetcher: don't use the cFetcher's allocator for other stuff#94674
craig[bot] merged 1 commit intocockroachdb:masterfrom
yuzefovich:clarify-cfetcher-allocator

Conversation

@yuzefovich
Copy link
Copy Markdown
Member

This commit fixes a minor bug in how we were accounting for the copy of the spans in the ColBatchScan. In particular, the cFetcher (or, more precisely, the colmem.SetAccountingHelper) requires that the allocator is not shared with other components (so that we could quickly get the footprint of the batch). This was violated in a single spot and is now fixed. The impact of this oversight is very minor - the set accounting helper would overestimate the footprint of the batch, so it could be returning batches smaller than the limit. Thus, the fix doesn't need to be backported.

I also audited other users of the set accounting helper and didn't find any other violations.

Epic: None

Release note: None

This commit fixes a minor bug in how we were accounting for the copy of
the spans in the ColBatchScan. In particular, the `cFetcher` (or, more
precisely, the `colmem.SetAccountingHelper`) requires that the allocator
is not shared with other components (so that we could quickly get the
footprint of the batch). This was violated in a single spot and is now
fixed. The impact of this oversight is very minor - the set accounting
helper would overestimate the footprint of the batch, so it could be
returning batches smaller than the limit. Thus, the fix doesn't need to
be backported.

I also audited other users of the set accounting helper and didn't find
any other violations.

Epic: None

Release note: None
@yuzefovich yuzefovich requested review from a team, DrewKimball and michae2 January 4, 2023 00:59
@cockroach-teamcity
Copy link
Copy Markdown
Member

This change is Reviewable

Copy link
Copy Markdown
Collaborator

@DrewKimball DrewKimball left a comment

Choose a reason for hiding this comment

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

:lgtm:

Maybe we should have operators that can't share an allocator construct it themselves. Not necessarily a suggestion for this PR, but wanted to get your thoughts on the idea.

Reviewed 3 of 3 files at r1, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @michae2)

@yuzefovich
Copy link
Copy Markdown
Member Author

It's a good question. The main pain point would be to provide a way to construct a memory account. My initial thought was that we could pass a reference to colexecargs.MonitorRegistry, but then I realized that this wouldn't work for the KV projection pushdown (we don't have access to the vectorized flow creator on the KV server side). I could see us passing a memory account instead of a colmem.Allocator, but that wouldn't make the interface less prone to errors. I guess we could define an "account provider" interface which would be backed by MonitorRegistry for most cases and would have a different implementation for the KV projection pushdown, but I'm not sure whether it's worth it. Curious to hear if you or Michael have some ideas.

TFTR!

bors r+

@craig
Copy link
Copy Markdown
Contributor

craig bot commented Jan 4, 2023

Build succeeded:

@craig craig bot merged commit 9e54d50 into cockroachdb:master Jan 4, 2023
@yuzefovich yuzefovich deleted the clarify-cfetcher-allocator branch January 4, 2023 17:55
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.

3 participants