Properly check index mark/restore in ExecSupportsMarkRestore.

Previously this code assumed that all IndexScan nodes supported
mark/restore, which is not true since it depends on optional index AM
support functions. This could lead to errors about missing support
functions in rare edge cases of mergejoins with no sort keys, where an
unordered non-btree index scan was placed on the inner path without a
protecting Materialize node. (Normally, the fact that merge join
requires ordered input would avoid this error.)

Backpatch all the way since this bug is ancient.

Per report from Eugen Konkov on irc.

Discussion: https://postgr.es/m/87o8jn50be.fsf@news-spur.riddles.org.uk
This commit is contained in:
Andrew Gierth 2020-11-24 20:58:32 +00:00
parent 340ae3cfb8
commit 6dda057043
3 changed files with 8 additions and 0 deletions

View File

@ -417,6 +417,11 @@ ExecSupportsMarkRestore(Path *pathnode)
{
case T_IndexScan:
case T_IndexOnlyScan:
/*
* Not all index types support mark/restore.
*/
return castNode(IndexPath, pathnode)->indexinfo->amcanmarkpos;
case T_Material:
case T_Sort:
return true;

View File

@ -275,6 +275,8 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
info->amhasgettuple = (amroutine->amgettuple != NULL);
info->amhasgetbitmap = amroutine->amgetbitmap != NULL &&
relation->rd_tableam->scan_bitmap_next_block != NULL;
info->amcanmarkpos = (amroutine->ammarkpos != NULL &&
amroutine->amrestrpos != NULL);
info->amcostestimate = amroutine->amcostestimate;
Assert(info->amcostestimate != NULL);

View File

@ -864,6 +864,7 @@ struct IndexOptInfo
bool amhasgettuple; /* does AM have amgettuple interface? */
bool amhasgetbitmap; /* does AM have amgetbitmap interface? */
bool amcanparallel; /* does AM support parallel scan? */
bool amcanmarkpos; /* does AM support mark/restore? */
/* Rather than include amapi.h here, we declare amcostestimate like this */
void (*amcostestimate) (); /* AM's cost estimator */
};