summaryrefslogtreecommitdiff
path: root/src/include/archive/shell_archive.h
diff options
context:
space:
mode:
authorPeter Eisentraut <peter@eisentraut.org>2025-10-28 10:06:03 +0100
committerPeter Eisentraut <peter@eisentraut.org>2025-10-28 10:07:29 +0100
commit35e53b68418a1d06f899d4bb41be88d18f9dcb7b (patch)
tree38954214f1f46b4c51dd232666044718990baeac /src/include/archive/shell_archive.h
parentf9a09aa2952039a9956b44d929b9df74d62a4cd4 (diff)
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
Diffstat (limited to 'src/include/archive/shell_archive.h')
0 files changed, 0 insertions, 0 deletions