That looks like a bug with how opened pipelines are not caught at the
end of the script processing. startpipeline seems to have similar
related issues.
$ cat only_startpipeline.sql
\startpipeline
SELECT 1;
With only 1 transaction, pgbench will consider this a success despite
not sending anything since the pipeline was not flushed:
pgbench -t1 -Mextended -f only_startpipeline.sql
[...]
number of transactions per client: 1
number of transactions actually processed: 1/1
With 2 transactions, the error will happen when \startpipeline is
called a second time:
pgbench -t2 -Mextended -f only_startpipeline.sql
[...]
pgbench: error: client 0 aborted in command 0 (startpipeline) of
script 0; already in pipeline mode
number of transactions per client: 2
number of transactions actually processed: 1/2
I've split the changes into two patches.
0001 introduces a new error when the end of a pgbench script is
reached while there's still an ongoing pipeline.
0002 adds the \syncpipeline command (original patch with an additional
test case).
Regards,
Anthonin
On Mon, Jan 22, 2024 at 7:16 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Jan 19, 2024 at 08:55:31AM +0100, Anthonin Bonnefoy wrote:
> > I've updated the doc to group the commands. It does look better and
> > more consistent with similar command groups like \if.
>
> I was playing with a few meta command scenarios while looking at this
> patch, and this sequence generates an error that should never happen:
> $ cat /tmp/test.sql
> \startpipeline
> \syncpipeline
> $ pgbench -n -f /tmp/test.sql -M extended
> [...]
> pgbench: error: unexpected transaction status 1
> pgbench: error: client 0 aborted while receiving the transaction status
>
> It looks to me that we need to be much smarter than that for the error
> handling we'd need when a sync request is optionally sent when a
> transaction stops at the end of pgbench. Could you look at it?
> --
> Michael