Re: Assert failure on running a completed portal again - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> Thanks for the research, and +1 if you feel like adding more commentary.

I'm thinking about something like this:

diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 13f3fcdaee..7ebb17fc2e 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -348,7 +348,15 @@ standard_ExecutorRun(QueryDesc *queryDesc,
         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 reason to be
+     * concerned about whether parallel query mode would operate properly if a
+     * fresh execution request arrives after completing the query.
      */
     if (!ScanDirectionIsNoMovement(direction))
         ExecutePlan(queryDesc,

It's slightly annoying that the executor is depending on the Portal
machinery to guarantee that it won't do something wrong.  However,
that was true in the previous formulation that relied on
Portal.run_once, too.   I don't see another way that wouldn't
amount to duplicating the Portal-level state in the executor,
and I don't think it's worth doing that.

            regards, tom lane