public inbox for [email protected]  

help / color / mirror / Atom feed

From: Durgamahesh Manne <[email protected]>
To: Adrian Klaver <[email protected]>
Cc: pgsql-general <[email protected]>
Subject: Re: pgbouncer transaction pool mode issue for prepared statements
Date: Tue, 17 Feb 2026 00:40:08 +0530
Message-ID: <CAJCZkoK1jumhXJWbmZfmPcgQaBZcU8paBf-RyZTSMCHAeprZUQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAJCZkoJr=Az5PMDj15O5ekzK+vK454WzoWZdQ9XUfTkTWtCQGw@mail.gmail.com>
	<[email protected]>

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

>
>

view thread (4+ messages)

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: <CAJCZkoK1jumhXJWbmZfmPcgQaBZcU8paBf-RyZTSMCHAeprZUQ@mail.gmail.com>

* 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