Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit c442722

Browse files
committed
Fix handling of REWIND/MARK/BACKWARD in incremental sort
The executor flags were not handled entirely correctly, although the bugs were mostly harmless and it was mostly comment inaccuracy. We don't need to strip any of the flags for child nodes. Incremental sort does not support backward scans of mark/restore, so MARK/BACKWARDS flags should not be possible. So we simply ensure this using an assert, and we don't bother removing them when initializing the child node. With REWIND it's a bit less clear - incremental sort does not support REWIND, but there is no way to signal this - it's legal to just ignore the flag. We however continue passing the flag to child nodes, because they might be useful to leverage that. Reported-by: Michael Paquier Author: James Coleman Reviewed-by: Tomas Vondra Discussion: https://postgr.es/m/20200414065336.GI1492@paquier.xyz
1 parent 6c29888 commit c442722

File tree

1 file changed

+10
-10
lines changed

1 file changed

+10
-10
lines changed

src/backend/executor/nodeIncrementalSort.c

Lines changed: 10 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -986,12 +986,11 @@ ExecInitIncrementalSort(IncrementalSort *node, EState *estate, int eflags)
986986
SO_printf("ExecInitIncrementalSort: initializing sort node\n");
987987

988988
/*
989-
* Incremental sort can't be used with either EXEC_FLAG_REWIND,
990-
* EXEC_FLAG_BACKWARD or EXEC_FLAG_MARK, because we only one of many sort
991-
* batches in the current sort state.
989+
* Incremental sort can't be used with EXEC_FLAG_BACKWARD or EXEC_FLAG_MARK,
990+
* because the current sort state contains only one sort batch rather than
991+
* the full result set.
992992
*/
993-
Assert((eflags & (EXEC_FLAG_BACKWARD |
994-
EXEC_FLAG_MARK)) == 0);
993+
Assert((eflags & (EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK)) == 0);
995994

996995
/* Initialize state structure. */
997996
incrsortstate = makeNode(IncrementalSortState);
@@ -1041,11 +1040,11 @@ ExecInitIncrementalSort(IncrementalSort *node, EState *estate, int eflags)
10411040
/*
10421041
* Initialize child nodes.
10431042
*
1044-
* We shield the child node from the need to support REWIND, BACKWARD, or
1045-
* MARK/RESTORE.
1043+
* Incremental sort does not support backwards scans and mark/restore, so
1044+
* we don't bother removing the flags from eflags here. We allow passing
1045+
* a REWIND flag, because although incremental sort can't use it, the child
1046+
* nodes may be able to do something more useful.
10461047
*/
1047-
eflags &= ~(EXEC_FLAG_REWIND | EXEC_FLAG_BACKWARD | EXEC_FLAG_MARK);
1048-
10491048
outerPlanState(incrsortstate) = ExecInitNode(outerPlan(node), estate, eflags);
10501049

10511050
/*
@@ -1126,7 +1125,8 @@ ExecReScanIncrementalSort(IncrementalSortState *node)
11261125
* store all tuples at once for the full sort.
11271126
*
11281127
* So even if EXEC_FLAG_REWIND is set we just reset all of our state and
1129-
* reexecute the sort along with the child node below us.
1128+
* re-execute the sort along with the child node. Incremental sort itself
1129+
* can't do anything smarter, but maybe the child nodes can.
11301130
*
11311131
* In theory if we've only filled the full sort with one batch (and haven't
11321132
* reset it for a new batch yet) then we could efficiently rewind, but

0 commit comments

Comments
 (0)