On 2/16/26 05:24, Durgamahesh Manne wrote:
Hi PGDG Team
We’re currently facing an issue with PgBouncer transaction pooling mode,
where prepared statements are failing, and we are unable to modify the
application code to disable or change how prepared statements are used.
Switching to session pooling mode is not feasible for us because we have
a very high number of connections that we cannot fully control.
Environment details: PgBouncer version: 1.25.1 PostgreSQL version: 16.11
The specific error we’re seeing is:
bind message has 43 result formats but query has 47 columns
ERROR: unnamed prepared statement does not exist Repeatedly logs
Has anyone encountered this issue with transaction pooling and
prepared statements? Are there any PgBouncer parameters or settings we
can use to mitigate this problem without requiring application‑level
changes? Any guidance or solutions would be greatly appreciated.
A little exploration/searching would have revealed:
https://www.pgbouncer.org/faq.html
5), How to use prepared statements with transaction pooling?
Which leads to:
https://www.pgbouncer.org/faq.html#how-to-use-prepared-statements-with-transaction-pooling
which in turn leads to:
https://www.pgbouncer.org/config.html#max_prepared_statements
Note though the caveat in last link:
"Note: This tracking and rewriting of prepared statement commands does
not work for SQL-level prepared statement commands, so PREPARE, EXECUTE
and DEALLOCATE are forwarded straight to Postgres. The exception to this
rule are the DEALLOCATE ALL and DISCARD ALL commands, these do work as
expected and will clear the prepared statements that PgBouncer tracked
for the client that sends this command."
Regards
Durga Mahesh
--
Adrian Klaver
[email protected]
