Thread

1. Re: Pgbench: remove synchronous prepare

   Dmitrii Bondar <d.bondar@postgrespro.ru> — 2026-05-05T07:48:30Z

   On 4/30/26 4:46 AM, Robert Haas wrote:
   > Why isn't the solution to use the existing PQsendPrepare function
   > instead of adding a new libpq entrypoint?
   
   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.
   
   > I don't think we
   > can add a function with a name like PQsendPBES, and I think we need to
   
   I have other suggestions:
   "PQsendQueryPrepare" but it is too close to the existing name 
   "PQsendQueryPrepared".
   "PQsendPrepareQuery" similar to "PQsendPrepare" but it also executes the 
   query.
   "PQsendPrepareExecute" is not especially well aligned with the existing 
   naming scheme, but it may describe the intent quite well.
   
   

2. Re: Pgbench: remove synchronous prepare

   Robert Haas <robertmhaas@gmail.com> — 2026-05-27T12:39:58Z

   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 \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