pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Check that index can return in get_actual_variable_range()
2+ messages / 1 participants
[nested] [flat]
* pgsql: Check that index can return in get_actual_variable_range()
@ 2025-10-28 09:17 Peter Eisentraut <peter@eisentraut.org>
0 siblings, 0 replies; 2+ messages in thread
From: Peter Eisentraut @ 2025-10-28 09:17 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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.schoemans@enterprisedb.com>
Discussion: https://www.postgresql.org/message-id/flat/20ED852A-C2D9-41EB-8671-8C8B9D418BE9%40enterprisedb.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/35e53b68418a1d06f899d4bb41be88d18f9dcb7b
Modified Files
--------------
src/backend/utils/adt/selfuncs.c | 7 +++++++
1 file changed, 7 insertions(+)
^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Check that index can return in get_actual_variable_range()
@ 2025-10-28 09:17 Peter Eisentraut <peter@eisentraut.org>
0 siblings, 0 replies; 2+ messages in thread
From: Peter Eisentraut @ 2025-10-28 09:17 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
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.schoemans@enterprisedb.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(+)
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-10-28 09:17 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-10-28 09:17 pgsql: Check that index can return in get_actual_variable_range() Peter Eisentraut <peter@eisentraut.org>
2025-10-28 09:17 pgsql: Check that index can return in get_actual_variable_range() Peter Eisentraut <peter@eisentraut.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox