public inbox for [email protected]  

help / color / mirror / Atom feed

From: Adrian Klaver <[email protected]>
To: Durgamahesh Manne <[email protected]>
To: pgsql-general <[email protected]>
Subject: Re: pgbouncer transaction pool mode issue for prepared statements
Date: Mon, 16 Feb 2026 08:05:48 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJCZkoJr=Az5PMDj15O5ekzK+vK454WzoWZdQ9XUfTkTWtCQGw@mail.gmail.com>
References: <CAJCZkoJr=Az5PMDj15O5ekzK+vK454WzoWZdQ9XUfTkTWtCQGw@mail.gmail.com>

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]

view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: pgbouncer transaction pool mode issue for prepared statements
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox