public inbox for [email protected]help / color / mirror / Atom feed
pgbouncer transaction pool mode issue for prepared statements 4+ messages / 3 participants [nested] [flat]
* pgbouncer transaction pool mode issue for prepared statements @ 2026-02-16 13:24 Durgamahesh Manne <[email protected]> 0 siblings, 2 replies; 4+ messages in thread From: Durgamahesh Manne @ 2026-02-16 13:24 UTC (permalink / raw) To: pgsql-general <[email protected]> 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 ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pgbouncer transaction pool mode issue for prepared statements @ 2026-02-16 13:36 Adrien Obernesser (OBA) <[email protected]> parent: Durgamahesh Manne <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: Adrien Obernesser (OBA) @ 2026-02-16 13:36 UTC (permalink / raw) To: Durgamahesh Manne <[email protected]>; pgsql-general <[email protected]> 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 protected]> Sent: Monday, February 16, 2026 2:24 PM To: pgsql-general <[email protected]> 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 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 ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pgbouncer transaction pool mode issue for prepared statements @ 2026-02-16 16:05 Adrian Klaver <[email protected]> parent: Durgamahesh Manne <[email protected]> 1 sibling, 1 reply; 4+ messages in thread From: Adrian Klaver @ 2026-02-16 16:05 UTC (permalink / raw) To: Durgamahesh Manne <[email protected]>; pgsql-general <[email protected]> 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] ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: pgbouncer transaction pool mode issue for prepared statements @ 2026-02-16 19:10 Durgamahesh Manne <[email protected]> parent: Adrian Klaver <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Durgamahesh Manne @ 2026-02-16 19:10 UTC (permalink / raw) To: Adrian Klaver <[email protected]>; +Cc: pgsql-general <[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 > > ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-02-16 19:10 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-02-16 13:24 pgbouncer transaction pool mode issue for prepared statements Durgamahesh Manne <[email protected]> 2026-02-16 13:36 ` Adrien Obernesser (OBA) <[email protected]> 2026-02-16 16:05 ` Adrian Klaver <[email protected]> 2026-02-16 19:10 ` Durgamahesh Manne <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox