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 |
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 |