Horton

Re: Assert failure on running a completed portal again

Yugo Nagata <nagata@sraoss.co.jp>

View thread View on postgr.es
From: Yugo Nagata <nagata@sraoss.co.jp>
To: Yugo Nagata <nagata@sraoss.co.jp>
Cc: pgsql-hackers@postgresql.org
Date: 2024-12-05T21:40:40Z
Lists: pgsql-hackers

Attachments

On Fri, 6 Dec 2024 06:25:49 +0900
Yugo Nagata <nagata@sraoss.co.jp> wrote:

> Hi,
> 
> I notice that the following Assert in PortalRun fails when a same portal is
> executed more than once by an Execute message whose "max number of rows"
> is specified to zero, that is, "no limit".  
> 
>         /* Set run_once flag.  Shouldn't be clear if previously set. */
>         Assert(!portal->run_once || run_once);
>         portal->run_once = run_once;
> 
> I tested this using pgproto [1] in Pgpool-II.
> 
> I believe the server should return CommanComplete normally in this case. 
> his can be fixed by not setting execute_is_fetch flag (run_once as the result)
> when the portal is already completed since no rows will be fetched in this case.
> I've attached a pach in this approach.
> 
> [1] https://www.pgpool.net/docs/latest/en/html/pgproto.html

Another idea is not call PortalRun in this case like the attached patch. 
Which approach is better? Or, should we fix in other approach?


> Regards,
> Yugo Nagata
> 
> -- 
> Yugo Nagata <nagata@sraoss.co.jp>


-- 
Yugo Nagata <nagata@sraoss.co.jp>

Commits

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

  2. Simplify executor's determination of whether to use parallelism.

  3. Allow for parallel execution whenever ExecutorRun() is done only once.