From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
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 22:09:14 |
Message-ID: | 2599319.1733436554@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> writes:
> 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;
Hmm. It's fairly hard to tell what was meant there, because
(a) there is exactly zero documentation of what run_once means
(b) that comment is opaque and doesn't appear to describe the
code behavior anyway.
> 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.
Don't like this much. I'm not sure I believe any part of this
approach to deciding whether the portal is "run once". In any
case, a proper fix for this needs to include actually documenting
what that field means and does.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-12-05 22:18:25 | 64 bit numbers vs format strings |
Previous Message | Ziga | 2024-12-05 22:09:12 | Re: Proposal to add a new URL data type. |