On Mon, 16 Feb, 2026, 21:35 Adrian Klaver, <[email protected]> wrote:
> 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] Hi Thank you so much for this information Regards Durga Mahesh > >
