fix: calculate decode priority correctly #2841
Merged
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.
When decoding we have to "wait until more than X rows are ready"
There was an issue with how we handled empty lists. For example, if the list offsets are:
The question is what do we do when we need to wait until more than 3 rows are ready. 3 rows means we have 60 items. The old logic looked for the next offset greater than 60 (i.e. 100) and waited until we had 100 items. This mirrors some logic we do on the reverse side when we calculate how many rows are available based on how many items we have.
However, that is wrong. If we have 60 items we actually have 4 rows available and so we have more than 3 rows available. The logic is much simpler. Just wait until we have at least
offsets[desired_rows + 1]
items. If that value is equal tooffsets[desired_rows]
it doesn't matter, we don't need to do any special logic.If we wait for too many rows it can lead to deadlock in certain situations.