Re: CommandStatus from insert returning when using a portal.

On Fri, Jul 14, 2023 at 10:39 AM <chap(at)anastigmatix(dot)net> wrote:

> On 2023-07-14 12:58, Dave Cramer wrote:
> > See attached pcap file
>
> So if the fetch count is zero and no portal is needed,
> or if the fetch count exceeds the row count and the command
> completion follows directly with no suspension of the portal, then
> it comes with the correct count, but if the portal gets suspended,
> then the later command completion reports a zero count?
>
>
I cannot really understand that output other than to confirm that all
queries had returning and one of them showed INSERT 0 0

Is there some magic set of arguments I should be using besides: tcpdump -Ar
filename ?

Because of the returning they all need a portal so far as the server is
concerned and the server will obligingly send the contents of the portal
back to the client.

I can definitely believe a bug exists in the intersection of a non-SELECT
query and a less-than-complete fetch count specification. There doesn't
seem to be any place in the core testing framework to actually test out the
interaction though...I even tried using plpgsql, which lets me open/execute
a plpgsql cursor with insert returning (which SQL prohibits) but we can't
get access to the command tag itself there. The ROW_COUNT variable likely
tracks actual rows fetched or seen (in the case of MOVE).

What I kinda suspect might be happening with a portal suspend is that the
suspension loop only ends when the final fetch attempt find zero rows to
return and thus the final count ends up being zero instead of the
cumulative sum over all portal scans.

David J.