| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Check that index can return in get_actual_variable_range() |
| Date: | 2025-10-28 09:17:07 |
| Message-ID: | E1vDfpD-003thl-2I@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
Check that index can return in get_actual_variable_range()
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, it was found that indexes 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(). Such an index might cause errors like
ERROR: no data returned for index-only scan
during query planning.
The fix is to add a check in get_actual_variable_range() to reject
indexes that do not allow index-only scans.
Author: Maxime Schoemans <maxime(dot)schoemans(at)enterprisedb(dot)com>
Discussion: https://www.postgresql.org/message-id/flat/20ED852A-C2D9-41EB-8671-8C8B9D418BE9%40enterprisedb.com
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/74197bdc842a280befe834e5cb4be700af9f8198
Modified Files
--------------
src/backend/utils/adt/selfuncs.c | 7 +++++++
1 file changed, 7 insertions(+)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2025-10-28 15:14:43 | Re: failed NUMA pages inquiry status: Operation not permitted |
| Previous Message | Michael Paquier | 2025-10-28 07:22:07 | pgsql: Add wal_fpi_bytes to pg_stat_wal and pg_stat_get_backend_wal() |