Re: [PATCH] Check that index can return in get_actual_variable_range() - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: [PATCH] Check that index can return in get_actual_variable_range()
Date
Msg-id CAJ7c6TM2nPjkW4bvnB7m+g_k6q5TT4KZQuxvQsXEAdGZJf8Pbg@mail.gmail.com
Whole thread Raw
In response to [PATCH] Check that index can return in get_actual_variable_range()  (Maxime Schoemans <maxime.schoemans@enterprisedb.com>)
Responses Re: [PATCH] Check that index can return in get_actual_variable_range()
Re: [PATCH] Check that index can return in get_actual_variable_range()
List pgsql-hackers
Hi Maxime,

> Some recent changes were made to remove the explicit dependency on btree indexes in some parts of the code. One of
thesechanges was made in commit 9ef1851685b, which allows non-btree indexes to be used in get_actual_variable_range().
Afollow-up commit ee1ae8b99f9 fixes the cases where an index doesn’t have a sortopfamily as this is a prerequisite to
beused in get_actual_variable_range(). However, I found out recently that indices that have ‘amcanorder = true’ but do
notallow index-only-scans (amcanreturn returns false or is NULL) will pass all of the conditions, while they should be
rejectedsince get_actual_variable_range() uses the index-only-scan machinery in get_actual_variable_endpoint(). 
>
> Attached is a small patch that adds a check in get_actual_variable_range() to reject indices that do not allow
index-onlyscans. 

Thanks for the patch.

Can you think of any test cases we can add to the code base?

--
Best regards,
Aleksander Alekseev



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Update Windows CI Task Names: Server 2022 + VS 2022 Upgrade
Next
From: Andres Freund
Date:
Subject: Re: ReadRecentBuffer() doesn't scale well