On 5/27/26 7:39 PM, Robert Haas wrote:
> On Tue, May 5, 2026 at 3:48 AM Dmitrii Bondar <d(dot)bondar(at)postgrespro(dot)ru> wrote:
> [ Catching up after pgconf.dev ]
>
> ... 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.
>
You are right that there is another solution, but it requires changes in other parts of pgbench. As I mentioned in my previous message, using PQsendPrepare is absolutely possible, but it would require changes to the pgbench state machine. In particular, a new state would be needed to wait asynchronously for the response to a Prepare message. The only reason I have not done that is that it would require rewriting code in several places, whereas adding a new libpq entry would mostly extend the code rather than modify the existing logic.