Subject: pgbouncer transaction pool mode issue for prepared statements

From: Durgamahesh Manne <[email-masked]>
Date: Mon, 16 Feb 2026 18:54:44 +0530

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.

Regards
Durga Mahesh

---

From: "Adrien Obernesser (OBA)" <[email-masked]>
Date: Mon, 16 Feb 2026 13:36:59 +0000

Hi,

It looks like you have the issue of a query that is referencing the prepared statements of another session. This is expected in transaction pooling mode. Since you are using this version of pgbouncer
try to look into the  max_prepared_statements parameter, I am not quite sure with the unnamed aspect though, this would need testing on your config.

Cordialement,  Kind Regards,

Adrien OBERNESSER

________________________________
From: Durgamahesh Manne <[email-masked]>
Sent: Monday, February 16, 2026 2:24 PM
To: pgsql-general <[email-masked]>
Subject: pgbouncer transaction pool mode issue for prepared statements

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

 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.

Regards
Durga Mahesh

---

From: Adrian Klaver <[email-masked]>
Date: Mon, 16 Feb 2026 08:05:48 -0800

On 2/16/26 05:24, Durgamahesh Manne wrote:
> 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
> 
>   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."

-- 
Adrian Klaver
[email-masked]

---

From: Durgamahesh Manne <[email-masked]>
Date: Tue, 17 Feb 2026 00:40:08 +0530

> for the client that sends this command."

Hi

Thank you so much for this information

Regards
Durga Mahesh