Skip to content

[PGPRO-11557] Fix infinite loop with multiple ORDER BY in RUM scan#149

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

Open
wants to merge 1 commit into
base:master
Choose a base branch
from

Conversation

LimarDeWills
Copy link

Fixes#66
Problem description:

When executing a query with ORDER BY col1, col2 using a RUM index, and the WHERE clause matches only a subset of the index, the query may enter an infinite loop in scanGetItemFast().

This occurs because entry->curItem is set via entry->curItem = collected.item;, but the corresponding entry->offset does not point to that item in entry->list. As a result, entryFindItem() may prematurely exit without correcting curItem, leading to repeated processing of the same item.
Fix:

Added an extra check in entryFindItem() that ensures:

curItem >= item offset is within valid range entry->curItem.iptr == entry->list[offset].iptr 

If the last condition fails, the function continues scanning the list to realign curItem and offset.

This ensures scanGetItemFast() progresses correctly and prevents infinite looping.

@LimarDeWillsLimarDeWillsforce-pushed the PGPRO-11557-fix-orderby-loop branch from b548636 to 74b4070CompareApril 28, 2025 10:08
@LimarDeWillsLimarDeWillsforce-pushed the PGPRO-11557-fix-orderby-loop branch from 74b4070 to 337b60eCompareApril 28, 2025 11:46
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
1 participant
@LimarDeWills
close