On Tue, May 5, 2026 at 3:48 AM Dmitrii Bondar <[email protected]> wrote: > pgbench is not designed to process a response to a Parse message alone, > because of meta-commands. For example, the \gset command 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 with PQsendQueryPrepared may > look like the exact solution, but it is not. PQsendQueryStart does not allow > more than one command to be sent unless pipeline mode is enabled. This could > be fixed in two ways: either by allowing libpq to send more than one command > when pipeline is disabled, or by adding a new state-machine state to pgbench. > Both options seem more invasive than the current solution. Adding a new libpq > function just for pgbench (at least for now) does not seem ideal either, 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
