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 1vL20Z-0018kd-0n for pgsql-odbc@arkaria.postgresql.org; Mon, 17 Nov 2025 16:23:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vL1zX-000v3j-2l for pgsql-odbc@arkaria.postgresql.org; Mon, 17 Nov 2025 16:22:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vL1zX-000v3b-1u for pgsql-odbc@lists.postgresql.org; Mon, 17 Nov 2025 16:22:11 +0000 Received: from pgintl.fastcrypt.com ([149.56.129.164]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vL1zT-0001SG-2U for pgsql-odbc@postgresql.org; Mon, 17 Nov 2025 16:22:10 +0000 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by pgintl.fastcrypt.com (Postfix) with ESMTPSA id 0694B201DB for ; Mon, 17 Nov 2025 11:22:03 -0500 (EST) Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-b735ce67d1dso552196566b.3 for ; Mon, 17 Nov 2025 08:22:03 -0800 (PST) X-Gm-Message-State: AOJu0YxjwHKNe6UzWYRky3eTVh3ajwxaWRxQ5Gs0lPu1OT8K57UaBt1m SVjVyhb/U+OrcWm6rf7Hh7zteCxtm8A8oxu3ucJXhv1/jEshbgefLcbbEgBz+G50PCKmx/RDjDW jjFOcbxpZ4MfqWKMA1zl8fJsGMyvefEk= X-Google-Smtp-Source: AGHT+IHW4o3dU5zWFHGSbLOtHe/n6V7n7zct1xhKxaloLtaaPVz8wY9BUQfxAo7EZw9GV2KIR8g5knQ5OClgJCpjZFE= X-Received: by 2002:a17:907:2d92:b0:b73:3b3c:6d58 with SMTP id a640c23a62f3a-b736793d195mr1469602366b.38.1763396522606; Mon, 17 Nov 2025 08:22:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cramer Date: Mon, 17 Nov 2025 11:21:45 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bkdMIcx790NXC7ku0qU-Rpd1W2tltLY1ueaOHtPE11JHRJjyhqRl4Pa1OI Message-ID: Subject: Re: Guidance on avoiding session pinning with psqlODBC and RDS Proxy To: Neeta Ghadge Cc: "pgsql-odbc@postgresql.org" Content-Type: multipart/alternative; boundary="0000000000005406440643ccbf9e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005406440643ccbf9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neeta, I'm curious why RDSProxy is pinning on this. I can't think of any reason to pin on a SHOW That said, I'm equally curious why psqlODBC is doing it, it doesn't really need to know the transaction isolation level Dave Cramer www.postgres.rocks On Mon, 17 Nov 2025 at 05:19, Neeta Ghadge wrote: > Hi, > We are currently using PostgreSQL 16.5 with the ODBC driver (psqlodbcw.so > version 17.00.0006) in an environment that relies on Amazon RDS Proxy. > > We have observed that the driver automatically issues the following SQL > statements at connection startup: > > *SET DateStyle =3D 'ISO';* > > *SET extra_float_digits =3D 2;* > > *SHOW transaction_isolation;* > > > > While harmless in most cases*, these queries cause AWS RDS Proxy to pin > sessions, which reduces pooling efficiency.* We can neutralize the SET > commands using RDS Proxy=E2=80=99s InitQuery feature, but SHOW > transaction_isolation still forces pinning. > > > > Could you please suggest recommended ways to handle this scenario when > using psqlODBC with RDS Proxy? Specifically, are there configuration > options or best practices to avoid or minimize session pinning while stil= l > maintaining ODBC compliance? > > > > Thank you for your guidance. > > > > > > *Thanks and Regards,* > > *Neeta Ghadge* > > > > This message and the information contained herein is proprietary and > confidential and subject to the Amdocs policy statement, you may review a= t > https://www.amdocs.com/about/email-disclaimer > > Amdocs Development Centre India Private Limited having CIN: > U72200PN2004PTC0188320 converted into Amdocs Development Centre India LLP > (A limited liability partner=C2=ADship with LLP Identification Number: > AAI-6901 effective 28th Feb 2017) > --0000000000005406440643ccbf9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neeta,

I'm curious wh= y RDSProxy is pinning on this. I can't think of any reason to pin on a = SHOW
That said, I'm equally curious why psqlODBC is doing it,= it doesn't really need to know the transaction isolation level

Dave Cramer
www.postgres.rocks


On Mon, 17 Nov 2025 at 05:19= , Neeta Ghadge <Neeta.Ghadge@= amdocs.com> wrote:

Hi,
We are currently using PostgreSQL 16.5 with the ODBC driver (psqlodbcw.so v= ersion 17.00.0006) in an environment that relies on Amazon RDS Proxy.

We have observed that the driver automaticall= y issues the following SQL statements at connection startup:<= /span>

SET DateStyle =3D 'ISO';=

SET extra_float_digits =3D 2;

SHOW transaction_isolation;<= /span>

=C2=A0

While harmless in most cases, these querie= s cause AWS RDS Proxy to pin sessions, which reduces pooling efficiency. We can neutralize the SET commands using RDS Proxy=E2=80=99s InitQuery feature, but SHOW transaction_isolation stil= l forces pinning.

=C2=A0

Could you please suggest recommended ways to = handle this scenario when using psqlODBC with RDS Proxy? Specifically, are = there configuration options or best practices to avoid or minimize session pinning while still maintaining ODBC complian= ce?

=C2=A0

Thank you for your guidance.

=C2=A0

=C2=A0

Thanks and Regards,

Neeta Ghadge<= span style=3D"font-size:11pt;color:rgb(14,40,65)">

=C2=A0

This message and the = information contained herein is proprietary and confidential and subject to= the Amdocs policy statement, you may review at https://www.amdocs.com/abo= ut/email-disclaimer

Amdocs Development Ce= ntre India Private Limited having CIN: U72200PN2004PTC0188320 converted int= o Amdocs Development Centre India LLP (A limited liability partner=C2=ADshi= p with=C2=A0LLP Identification Number: AAI-6901 effective 28th Feb 2017)

--0000000000005406440643ccbf9e--