Re: Pgbench: remove synchronous prepare

> On 15 Jul 2026, at 16:03, Бондарь Дмитрий <d(dot)bondar(at)postgrespro(dot)ru> wrote:
>
> <v4-0001-add-wait-prepare-state.patch>

Hi Dmitrii,

I think this is worth fixing in pgbench itself. The benefit is not
limited to poolers: a prepare waiting for a table lock can also stall
unrelated clients on the same worker thread. That introduces a
dependency between clients into the generated workload, rather than
measuring how the server handles their independent requests.

The additional state seems a reasonable maintenance cost for fixing
that. It fits pgbench's existing model of waiting for each connection
through the event loop, and keeps the change local instead of extending
libpq's public API. I think this is the right direction, with a couple
of issues in the state transitions below.

Returning to CSTATE_START_COMMAND after preparing resets stmt_begin.
This drops the prepare time from --report-per-command. In a local test,
blocking Prepare on a table lock gave 4436 ms transaction latency
but only 0.401 ms statement latency. Could we send the query without
resetting the command timer?

The second PQgetResult() in CSTATE_WAIT_PREPARE_RESULT can still block:
the first returns ParseComplete, but the next must wait for
ReadyForQuery if it has not arrived yet. The error path also drains
results synchronously through getSQLErrorStatus(). Similar reads
already exist elsewhere in pgbench, but this leaves a blocking window
in the new prepare path. Could we wait for completion through the
event loop? A connection failure between the two results can also
make the second call return an error rather than the asserted NULL.

I also found a way to test the main fix without PgBouncer. With
-c 2 -j 1, use client_id to make client 0 select from a table locked
by another session in ACCESS EXCLUSIVE mode, and client 1 insert into
a different table. In local runs, client 1 made progress while
client 0 was blocked in Prepare with v4, but not without the patch.
This would test the intended behavior more directly than the changed
syntax-error expectation.

I am fine with leaving prepareCommandsInPipeline() for a separate patch.
Could the commit message describe this as a scope choice? Preparing
before PQenterPipelineMode() preserves the required ordering, but does
not require blocking the worker thread. The prepared-flag fix is also
limited to the non-pipeline path: prepareCommand() still sets the flag
after an error.

Thank you!

Best regards, Andrey Borodin.