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 1vL2LH-001OmE-3A for pgsql-odbc@arkaria.postgresql.org; Mon, 17 Nov 2025 16:44:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vL2LG-0010tr-1g for pgsql-odbc@arkaria.postgresql.org; Mon, 17 Nov 2025 16:44:38 +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 1vL2LG-0010tj-0q for pgsql-odbc@lists.postgresql.org; Mon, 17 Nov 2025 16:44:38 +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 1vL2LE-0001e0-0l for pgsql-odbc@postgresql.org; Mon, 17 Nov 2025 16:44:38 +0000 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by pgintl.fastcrypt.com (Postfix) with ESMTPSA id ADF2220029 for ; Mon, 17 Nov 2025 11:44:32 -0500 (EST) Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-b73a9592fb8so144999366b.1 for ; Mon, 17 Nov 2025 08:44:32 -0800 (PST) X-Gm-Message-State: AOJu0Yx0MzfF9hYYAg1+nT8UdxhwQlK5/ruHPidSr3rUF/tMAqL7RB9P XlV76pPAE5o8uhV2hQdNWDwWa8bNXIuZdMmbvqW+CkMTD1K6hq00mpmGOFCIcxLwVym8TIx+h8q V5PK0B1D3cbUuRRq88K2BJSPDABZOxZw= X-Google-Smtp-Source: AGHT+IHdnOWdLBcy9XwJOjXK40k4xHCVId69Fc45czFh3osTauJNblCD8lvb8gTTEb6qqJS10f1jFtwFwEnCurwWwcY= X-Received: by 2002:a17:906:f8db:b0:b72:6330:e651 with SMTP id a640c23a62f3a-b7365ac05e1mr1033441566b.21.1763397871805; Mon, 17 Nov 2025 08:44:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cramer Date: Mon, 17 Nov 2025 11:44:15 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bnGEsOhNEjmevk4ktlbByWyH-aY9SMIWJSzRemBY3nImNvfuqbaVeShv_k 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="000000000000bf2d870643cd0fe5" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bf2d870643cd0fe5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Neeta, Talking to some folks at Amazon, they don't think it should pin. Can you open a ticket with them? Dave Cramer www.postgres.rocks On Mon, 17 Nov 2025 at 11:21, Dave Cramer wrote= : > 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 reall= y > 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.s= o >> 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 sti= ll >> 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 = at >> https://www.amdocs.com/about/email-disclaimer >> >> Amdocs Development Centre India Private Limited having CIN: >> U72200PN2004PTC0188320 converted into Amdocs Development Centre India LL= P >> (A limited liability partner=C2=ADship with LLP Identification Number: >> AAI-6901 effective 28th Feb 2017) >> > --000000000000bf2d870643cd0fe5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Neeta,

Talking to some folks at Amazon, they don't think it should pin= . Can you open a ticket with them?

Dave Cramer
www.postgres.rocks

On Mon, 17 Nov 2025 at 11:21, Dave Cramer <davecramer@po= stgres.rocks> wrote:
Hi Neeta,

I'm cu= rious why RDSProxy is pinning on this. I can't think of any reason to p= in on a SHOW
That said, I'm equally curious why psqlODBC is d= oing 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)

--000000000000bf2d870643cd0fe5--