Re: Assert failure on running a completed portal again

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Assert failure on running a completed portal again
Date: 2024-12-05 21:40:40
Message-ID: 20241206064040.65f84c65d87be0339fc42070@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 6 Dec 2024 06:25:49 +0900
Yugo Nagata <nagata(at)sraoss(dot)co(dot)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(at)sraoss(dot)co(dot)jp>

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

Attachment Content-Type Size
portal_assert_another_way.patch.txt text/plain 862 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ziga 2024-12-05 22:09:12 Re: Proposal to add a new URL data type.
Previous Message Yugo Nagata 2024-12-05 21:25:49 Assert failure on running a completed portal again