Fix updating the diskArray nextPipPageIdx when multiple new PIPs are added #3329
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Silly mistake on my part here, as I guess I made it unconditionally set the
nextPipPageIdx
on theupdatedLastPIP
when doing the pip caching optimization in #3189.The test suite doesn't have any copies large enough to trigger this, as we only add multiple PIPs in a single transaction when copying
1023 * 16
slots (num AP indexes per pip index page times the number of slots per page), or roughly 58 million primary keys (divided among 256 indexes with 14 entries per slot for an int64 slot).This should be reproduce-able on the second copy, but won't encounter a failure without doing look-ups on certain keys or doing a third copy.
I'll add a larger copy test in a future PR once the performance has improved a little more, as the multi copy test is already very slow in debug mode.