Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WT-12178: bug fix, __wt_block_extlist_merge has potential risks #10015

Conversation

y123456yz
Copy link
Contributor

@y123456yz y123456yz commented Dec 18, 2023

__wt_block_extlist_merge has potential risks.

in function __wt_block_extlist_merge, We switched a and b,this may leads to the following potential risks:

  1. Since the contents of a have changed after the swap, we can't use a in the outer layer of the function.
  2. If we add a new variable to WT_EXTLIST, It's easy to miss the exchange of new variables here.

in PR: #9896
https://github.com/y123456yz/wiredtiger/blob/develop_WT_EXTLIST_last_bug_fix/src/block/block_ext.c#L955-L956

Because of this problem, some unit test run failed, it took me a lot of time to locate. So it's worth adding some comments and WT_UNUSED here.

michaelcahill and others added 30 commits December 7, 2017 10:48
Record how many pages we want and how many pages we have queued so far
in a tree, then resume the walk next iteration.  This avoids a single
tree with a target larger than the queue size being walked completely
before the eviction server moves on to the next tree.
(cherry picked from commit fca6a8d)
There's trickiness in the page-pinned check. By definition a remove
operation leaves a cursor positioned if it's initially positioned.
However, if every item on the page is deleted and we unpin the page,
eviction might delete the page and our search will re-instantiate an
empty page for us. Cursor remove returns not-found whether or not
that eviction/deletion happens and it's OK unless cursor-overwrite
is configured (which means we return success even if there's no item
to delete). In that case, we'll fail when we try to point the cursor
at the key on the page to satisfy the positioned requirement. It's
arguably safe to simply leave the key initialized in the cursor (as
that's all a positioned cursor implies), but it's probably safer to
avoid page eviction entirely in the positioned case.

(cherry picked from commit 2ac616e)
Copy link

Hi @y123456yz, thank you for your submission!
Please make sure to sign our Contributor Agreement (if you haven't already) and provide us with editor permissions on your branch. Instructions on how do that can be found here.

@y123456yz
Copy link
Contributor Author

WT-12178

@y123456yz y123456yz changed the title bug fix, __wt_block_extlist_merge has potential risks WT-12178: bug fix, __wt_block_extlist_merge has potential risks Dec 18, 2023
@korteland
Copy link
Contributor

@y123456yz I don't think this is broken, risky, or worth fixing sorry. Merging extent lists is an operation that we expect to alter the extent lists that we pass in.

Even if we wanted to make this change, I don't think it's useful to mark fields of a structure with WT_UNUSED like this - ultimately if some logic needs to use a variable, it needs to be responsible for using that variable correctly.

@korteland korteland closed this Feb 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants