Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vrybz-00FrzV-2X for pgsql-general@arkaria.postgresql.org; Mon, 16 Feb 2026 13:26:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vryaz-002Y8R-1h for pgsql-general@arkaria.postgresql.org; Mon, 16 Feb 2026 13:25:01 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vryaz-002Y8G-0V for pgsql-general@lists.postgresql.org; Mon, 16 Feb 2026 13:25:01 +0000 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vryaw-00000000tW3-1nb7 for pgsql-general@lists.postgresql.org; Mon, 16 Feb 2026 13:25:00 +0000 Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b8f8f2106f1so414832766b.2 for ; Mon, 16 Feb 2026 05:24:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771248297; cv=none; d=google.com; s=arc-20240605; b=dUgggCN5FZasYCd2VTt1nj7cQIOPXe/pc0dFVkrbQo8HMQD5qYBAHlftsm/oqLmXtK azFrHyjCd9EBmhrIdTa4Jqz9VOcqZpohz4VtdeaLUToFP/gF1lW4/vNAKd4Y8ePNVj9h FHAolOMTwqzQLnTbNLD1MitRyFsWn8DARLJI7FXk9UdgFrjMhWiegB9GrhgNUnEZ0VsR i/6WK39gdy/hbVKTXaxPpVyNOInx3ALpWrAAcg+9+bW+iLE27+VRu43ZLXs6Rzml4LnO BHUv5g8rjJrnPBdhehC2sLpEu/psCRkbyi0HEAPT8yg0hrDMvzHdUN2ww1tWLLRHjIGr JS/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=HRCLWUuemN10wTuctOoud0jtWTh+CsmCIPa4/cK3vbY=; fh=U9Vkrj/8YXu+wNKP4ImG87p6jlJYRxuB/zicT9qNons=; b=S2uXodVfRtmDQY0Mjlr97/sFdMqwA6OcVVxDuzVVu2XnazSpv43FgIFrCiCfaK6O+2 2YUnCWnJjEzVy5vFe7ghgHx+FbUnYMmFD6Mo+CQZ+Fx66Ma/uhZL7LF+nETgdfJqjx7E gFghxqQwB/kGvH20C1mG8apDz4Y4PrqqPiy8cb6p7oI3nd9Su6/9ysEx9zkFYY+5iQzD 1hsk03gy0o7FQJxeY6+qvPdB/hTYKhKSgNuibmjfX+l9l4QuxyubIORYW3e3vBlDsNK9 zci7Up7ZMiOeQilXsSnY7/9hUl8ovKHSdLx8MYik8wWjkiay7bbQ2/O/sopHNMHDDfee K3FQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771248297; x=1771853097; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=HRCLWUuemN10wTuctOoud0jtWTh+CsmCIPa4/cK3vbY=; b=BUpJKVspTiWMtsM0xe6k3ieuQn5LjrQWs3BvOnBViX8GSKCmyucvz9yFBj+GBR66EM jw080ILB1k9Q/jbgFsWfMLkfRno3LvMxEIU/2w7iegUWqWl6NxwP72msJ/rQPUPwwePE YsPcGpcUOUZigOWdI24Nt62ybbQNvhE7Q5MRScGz6B5MUpAPMRZhYfjqgA2RJ+dDo38H SvRLLdXXGo09MVrylnwgu0YP/El2e1g1ER3938Zd+caKBOCdZJbQ9A8CZ80k/XCElnAg i+Xls1suspLUllAIRtpxovEfXquTPxlw4vl+ETmfQirlkCU9HL//3sU6620fgY0Eccqo R7QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771248297; x=1771853097; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HRCLWUuemN10wTuctOoud0jtWTh+CsmCIPa4/cK3vbY=; b=L8RMGEBoYSt9zW7qv1Ezfi1TgBROzgbs7K4u8SiUzxPYY3Q1lL1lTeHtgL79dPa+Ri PZZspa9ypCP/tNYHwGoFn/rhsyx06NqzqGtuMyXnV8l/IJb9Ws0i6vRKCuOb79A8CVW6 Nq5kg/spMQBNs5+Pqj0EYld2IJsj2T3FYsoIx0vNmZy6mgSO8WkWy19nJIbJgrDEAyrE mA0i7rJTJFjDv9LtqAZ6iqkOJtV8V23C5xNA1gFZOc8f1Tl7WmLV218siKuy2IBwTbZy 9ECk1quhQ1NXf8FcaipnG3kiHin3WqNmLzfo474CVPSaL19ekb00DB1qsV+ADxEKjwX2 rtSw== X-Gm-Message-State: AOJu0YyIAe7bCknIz8YhIE6SdzB0C90tOFGZETBcv58qfDPXEfHyHQB6 tlJbp5wLJmfdAJG/fUEK/6NltAb0q5EjajCWSYdb/hOqEG8us5lsYnFQ9VfR97TPFxMBU+rc1ye pV5PO+E59W0Nv1k2cuNWyqM8+KAsGKTvvrw== X-Gm-Gg: AZuq6aLOR8KzhMHjkkfqpv/3hbG+dYHIw9Eqk/ODayS2f5/tT+lx/xmHDBNv8yRQR87 FWWbE/PQ/uxATMWbomZYwwB3AegzNzXgeBK9HSnpm9J2qwqtZchLAuLScki8uMWnDynvkiuvVUc AbY4OHhmRFS1cSNwuNPNywC8VLctVXta/r3CnU6sjtKrMZVoctuEuuF8i4DVs+YnyEmPtgExrxC CK03lorLxWO+lyt/BAimPBVJgkjWdsl2nbD8Jjyeu/5EeYf25Qy5aPrN01b+i0+/7AM933UY5by r/tenm+ibSN9bd2F8wvzSttsLYM2VbXIkqEc32s= X-Received: by 2002:a17:907:3f08:b0:b8f:96f3:de05 with SMTP id a640c23a62f3a-b8fc3d320d0mr365654966b.60.1771248297347; Mon, 16 Feb 2026 05:24:57 -0800 (PST) MIME-Version: 1.0 From: Durgamahesh Manne Date: Mon, 16 Feb 2026 18:54:44 +0530 X-Gm-Features: AZwV_QgNgyKS8a2rTrBlV7HZxE5B7lbyQE9FW-MkLEpS-GD6ikQMEFm12wtTc0Y Message-ID: Subject: pgbouncer transaction pool mode issue for prepared statements To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000929081064af0e1fa" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000929081064af0e1fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi PGDG Team We=E2=80=99re 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=E2=80=99re 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=E2=80=91level changes? = Any guidance or solutions would be greatly appreciated. Regards Durga Mahesh --000000000000929081064af0e1fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi PGDG Team=C2=A0



We=E2=80=99re curr= ently facing an issue with PgBouncer transaction pooling mode, where prepar= ed 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 fe= asible for us because we have a very high number of connections that we can= not fully control. Environment details: PgBouncer version: 1.25.1 PostgreSQ= L version: 16.11

=C2=A0T= he specific error we=E2=80=99re seeing is:=C2=A0
bind message has 43 result formats but query has 4= 7 columns

ERROR: unnamed= prepared statement does not exist Repeatedly logs=C2=A0

=C2=A0Has anyone encountered this issue wi= th transaction pooling and prepared statements? Are there any PgBouncer par= ameters or settings we can use to mitigate this problem without requiring a= pplication=E2=80=91level changes? Any guidance or solutions would be greatl= y appreciated.

Regards= =C2=A0
Durga Mahesh
--000000000000929081064af0e1fa--