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 1vL64Q-003sFJ-1v for pgsql-odbc@arkaria.postgresql.org; Mon, 17 Nov 2025 20:43:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vL63P-0020TF-0c for pgsql-odbc@arkaria.postgresql.org; Mon, 17 Nov 2025 20:42:27 +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 1vL63O-0020T6-2q for pgsql-odbc@lists.postgresql.org; Mon, 17 Nov 2025 20:42:27 +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 1vL63F-0003Ws-1u for pgsql-odbc@postgresql.org; Mon, 17 Nov 2025 20:42:21 +0000 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by pgintl.fastcrypt.com (Postfix) with ESMTPSA id 8B5C020229 for ; Mon, 17 Nov 2025 15:42:13 -0500 (EST) Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-b7370698a8eso448728366b.0 for ; Mon, 17 Nov 2025 12:42:13 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCV3cpB5Ayg6WqhgHzuyZOnKYs3K8RY63mQSTz/m5iEoAGTYalzi4RZBn8TEod4fhgCxjNdNxeeoBLiA@postgresql.org X-Gm-Message-State: AOJu0YyGXsCESzpwD7xnKbJfR7j4XwgYFi9S6fEboqeeaXLuj0tSPZqs KluhJAk7agFYQWWVRNo2R9JWrQvVUm4H8IQej/++FmY31kW0YClbWznmkzNvh36jGUw8Wc3VNIY GeyxSdcOwoIrCNN7tym6sV7QXewaw/nY= X-Google-Smtp-Source: AGHT+IH44gi1EdP0d7Tfr/Bzt+wx6TCxS8/0z1d43V5zymkxVwsexYk2LhiVwNxow5VTD420Sr7vx4H3iqKKviAxFs8= X-Received: by 2002:a17:906:fe0e:b0:b6d:6c1a:31ae with SMTP id a640c23a62f3a-b7367be062bmr1566973666b.49.1763412132183; Mon, 17 Nov 2025 12:42:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cramer Date: Mon, 17 Nov 2025 15:41:53 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bkY29TM_8gjshfZp6-4iVIs4g9JBF5cF3IAy7dRh_K8avq2Qv15jMNRwlE Message-ID: Subject: Re: Guidance on avoiding session pinning with psqlODBC and RDS Proxy To: Jon Raiford Cc: Neeta Ghadge , "pgsql-odbc@postgresql.org" Content-Type: multipart/alternative; boundary="000000000000bb42bb0643d06168" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000bb42bb0643d06168 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I know how to fix it. Working on it. Dave Cramer www.postgres.rocks On Mon, 17 Nov 2025 at 12:23, Jon Raiford wrote: > Here is the RDS documentation for this: > > > https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy-pinning.= html > > There was mention by OP of using InitQuery, but my understanding is that > as long as the driver makes the set call that the pinning will happen > regardless of what state the connection is currently in. My research also > showed that the show command should not have affected the pinning. > > Jon > > > *From: *Dave Cramer > *Date: *Monday, November 17, 2025 at 12:13=E2=80=AFPM > *To: *Neeta Ghadge > *Cc: *pgsql-odbc@postgresql.org > *Subject: *Re: Guidance on avoiding session pinning with psqlODBC and RDS > Proxy > > Ah, > > OK, I will have to change the driver. I think that is doable. > > Can you create an issue here > https://github.com/postgresql-interfaces/psqlodbc > > Dave Cramer > www.postgres.rocks > > > On Mon, 17 Nov 2025 at 11:52, Neeta Ghadge > wrote: > > Hi, > Thank you for your prompt response. > It=E2=80=99s not SHOW command, rather it is *SET* that is causing session > pinning. I will try to find alternate approaches to avoid session pinning= . > > > > > > *Thanks and Regards,* > > *Neeta Ghadge* > > > > *From:* Dave Cramer > *Sent:* Monday, November 17, 2025 10:14 PM > *To:* Neeta Ghadge > *Cc:* pgsql-odbc@postgresql.org > *Subject:* Re: Guidance on avoiding session pinning with psqlODBC and RDS > Proxy > > > > You don't often get email from davecramer@postgres.rocks. Learn why this > is important > > *CAUTION:* This email is from an external source. Please don=E2=80=99t op= en any > unknown links or attachments. > > 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.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) > > 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) > > --000000000000bb42bb0643d06168 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I know how to fix it. Working on it.
<= div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature= ">
Dave Cramer
www.postgres.rocks


On Mon, 17 Nov 2025 at 12:23, Jon Raiford <= ;raiford@labware.com> wrote:<= br>
Here is the RDS documentation for this:


There was mention by OP of using InitQuery, but my understanding is that as= long as the driver makes the set call that the pinning will happen regardl= ess of what state the connection is currently in. My research also showed t= hat the show command should not have affected the pinning.

Jon

=C2=A0

From: Dave Cramer <davecramer@postgres.rocks>
Date: Monday, November 17, 2025 at 12:13=E2=80=AFPM
To: Neeta Ghadge <Neeta.Ghadge@amdocs.com>
Cc: p= gsql-odbc@postgresql.org <pgsql-odbc@postgresql.org>
Subject: Re: Guidance on avoiding session pinning with psqlODBC and = RDS Proxy

Ah,

OK, I will have to change the driver. I think that is doab= le.=C2=A0


Dave Cramer
www.postgres.rocks


On Mon, 17 Nov 2025 at 11:52, Neeta G= hadge <Neet= a.Ghadge@amdocs.com> wrote:

Hi,
Thank you for your prompt response.
It=E2=80=99s not SHOW command, rather it is SET=C2=A0that is causing= session pinning. I will try to find alternate approaches to avoid session = pinning.

=C2=A0

=C2=A0

Thanks and Regards,<= /span>

Neeta Ghadge<= /p>

=C2=A0

From:=C2=A0Dave Cramer <davecramer@postgres.rocks> Sent:=C2=A0Monday, November 17, 2025 10:14 PM
To:=C2=A0Neeta Ghadge <Neeta.Ghadge@= amdocs.com>
Cc: pgsql-odbc@postgresql.org
Subject:=C2=A0Re: Guidance on avoiding session pinning with psqlODBC= and RDS Proxy

=C2=A0

You don't often get email from davecramer@postgres.rocks. Learn why this is important

CAUTION:=C2=A0This email is from an external source. P= lease don=E2=80=99t open any unknown links or attachments.

Hi,

=C2=A0

Neeta,

=C2=A0

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

=C2=A0

Dave Cramer

www.postgres.rocks

=C2=A0

=C2=A0

On Mon, 17 Nov 2025 at 11:21, Dave Cramer <davecramer@postgres.rocks> wrote:

Hi Neeta,

=C2=A0

I'm curious why RDSProxy is pinning on this. I c= an't think of any reason to pin 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=

=C2=A0

Dave Cramer

www.postgres.rocks

=C2=A0

=C2=A0

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:

SET DateStyle =3D 'ISO';

SET extra_float_digits =3D 2;

SHOW transaction_isolation;

=C2=A0

While harmless in most cases, these querie= s cause AWS RDS Proxy to pin sessions, which reduces pooling efficiency.=C2=A0We can neutralize the SET commands using RDS Proxy=E2=80=99s InitQuery feature, but SHOW transaction= _isolation still 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 maintai= ning ODBC compliance?

=C2=A0

Thank you for your guidance.

=C2=A0

=C2=A0

Thanks and Regards,<= /span>

Neeta Ghadge<= /p>

=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/about/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)

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 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)

--000000000000bb42bb0643d06168--