On Tue, May 5, 2026 at 3:48 AM Dmitrii Bondar <d.bondar@postgrespro.ru> wrote:
> pgbench is not designed to process a response to a Parse message alone, because of meta-commands. For example, the
\gsetcommand requires a tuple to be stored, but a response to a Parse message does not provide one. This leads to the
error:pgbench: error: client 0 script 0 command 0 query 0: expected one row, got 0. Sending all additional messages
withPQsendQueryPrepared may look like the exact solution, but it is not. PQsendQueryStart does not allow more than one
commandto be sent unless pipeline mode is enabled. This could be fixed in two ways: either by allowing libpq to send
morethan one command when pipeline is disabled, or by adding a new state-machine state to pgbench. Both options seem
moreinvasive than the current solution. Adding a new libpq function just for pgbench (at least for now) does not seem
idealeither, but it may be simpler and safer.
[ Catching up after pgconf.dev ]
I think there's something I'm still not understanding here. What you
said was that PQprepare can block, and I suggested using
PQsendPrepare. But your respond seems to be about PQsendQueryPrepared,
which is something different. I feel like if pgbench is using a
blocking call (like PQprepare) there should be a solution possible by
using the non-blocking variant of the same function (which in this
case is PQsendPrepare). If using that causes pgbench to die with some
weird error, that seems like a sign that other parts of pgbench also
need a bit of adjustment, rather than a sign that we need a new libpq
entrypoint.
--
Robert Haas
EDB: http://www.enterprisedb.com
