[PATCH] Check that index can return in get_actual_variable_range()

Maxime Schoemans <maxime.schoemans@enterprisedb.com>

From: Maxime Schoemans <maxime.schoemans@enterprisedb.com>

To: pgsql-hackers@lists.postgresql.org

Cc: Mark Dilger <mark.dilger@enterprisedb.com>

Date: 2025-09-17T10:16:44Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Check that index can return in get_actual_variable_range()
- 74197bdc842a 18.1 landed
- 35e53b68418a 19 (unreleased) landed
Fix crash/valgrind error
- ee1ae8b99f96 18.0 cited
Support non-btree indexes in get_actual_variable_range()
- 9ef1851685b7 18.0 cited

Attachments

v1-0001-Check-that-index-can-return-in-get_actual_variabl.patch (application/octet-stream) patch v1-0001

Hi all,

Some recent changes were made to remove the explicit dependency on btree indexes in some parts of the code. One of these changes was made in commit 9ef1851685b, which allows non-btree indexes to be used in get_actual_variable_range(). A follow-up commit ee1ae8b99f9 fixes the cases where an index doesn’t have a sortopfamily as this is a prerequisite to be used in get_actual_variable_range(). However, I found out recently that indices that have ‘amcanorder = true’ but do not allow index-only-scans (amcanreturn returns false or is NULL) will pass all of the conditions, while they should be rejected since 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-only scans.

Regards,
Maxime Schoemans