| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Dmitrii Bondar <d(dot)bondar(at)postgrespro(dot)ru> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Pgbench: remove synchronous prepare |
| Date: | 2026-04-29 21:46:31 |
| Message-ID: | CA+TgmoYnWeA_jOOdebo=vfaCFAUYk2mMd5cPm4a_FnSMu_4ozA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 28, 2026 at 5:29 AM Dmitrii Bondar <d(dot)bondar(at)postgrespro(dot)ru> wrote:
> Session mode is indeed the most transparent way to use a pooler. However, pgbench can become stuck when the number of clients exceeds the pool size. If the pooler cannot reserve a backend for a client, it places the client in a waiting queue. In that case, pgbench may wait indefinitely because it is blocked in PQprepare, and the pgbench thread cannot process responses for other clients.
Ah, I see! This is a key point I wasn't understanding previously.
Why isn't the solution to use the existing PQsendPrepare function
instead of adding a new libpq entrypoint?
Even if we stick with the design you propose here, I don't think we
can add a function with a name like PQsendPBES, and I think we need to
find a way to more clearly explain what it does. It's kind of
unfortunate that there's such a large gap between the names of the
functions and the protocol messages that they send, but if all the
other functions are named without reference to the underlying protocol
messages, and this one is an exception, then it seems like it's going
to be hard to understand.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2026-04-30 00:40:52 | Re: Experimenting with wider Unicode storage |
| Previous Message | Mohamed ALi | 2026-04-29 21:36:09 | Re: [PATCH] Fix: Partitioned parent index remains invalid after child indexes are repaired |