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.
