database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-25 20:23:07 +03:00
Code Activity

Doc: add some commentary about ExecutorRun's NoMovement special case.

Browse Source 
Robert Haas expressed concern about whether commit 3eea7a0c9 exposed
the parallel-execution machinery to a case it isn't tested for, namely
a second non-parallel execution of a plan after a parallel execution.
Investigation shows that that can't happen because of pquery.c's
manipulation of the scan direction, but it sure wasn't obvious to
start with.  Add some commentary about that.

Discussion: https://postgr.es/m/CA+TgmoagyKQy=HFw+wLo0AKTYWHui+iKswZ8Jnqqd-cFby-WVg@mail.gmail.com
This commit is contained in:
Tom Lane
2024-12-10 17:17:28 -05:00
parent 8b9cbf4922
commit 9828905303
1 changed files with 10 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
src/backend/executor/execMain.c
View File

@@ -348,7 +348,16 @@ standard_ExecutorRun(QueryDesc *queryDesc,
dest->rStartup(dest, operation, queryDesc->tupDesc); dest->rStartup(dest, operation, queryDesc->tupDesc);
/* /*
* run plan * Run plan, unless direction is NoMovement.
*
* Note: pquery.c selects NoMovement if a prior call already reached
* end-of-data in the user-specified fetch direction. This is important
* because various parts of the executor can misbehave if called again
* after reporting EOF. For example, heapam.c would actually restart a
* heapscan and return all its data afresh. There is also some doubt
* about whether a parallel plan would operate properly if an additional,
* necessarily non-parallel execution request occurs after completing a
* parallel execution. (That case should work, but it's untested.)
*/ */
if (!ScanDirectionIsNoMovement(direction)) if (!ScanDirectionIsNoMovement(direction))
ExecutePlan(queryDesc, ExecutePlan(queryDesc,