Re: Pgbench: remove synchronous prepare - Mailing list pgsql-hackers

From Dmitrii Bondar
Subject Re: Pgbench: remove synchronous prepare
Date
Msg-id 6cf1ae29-0992-4a14-a52f-b769b560b92a@postgrespro.ru
Whole thread
In response to Re: Pgbench: remove synchronous prepare  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


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.


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Server crash: Use-after-free in AfterTriggerEndQuery()
Next
From: Henson Choi
Date:
Subject: Re: Improve the performance of Unicode Normalization Forms.