Re: Guidance on avoiding session pinning with psqlODBC and RDS Proxy
| От | Dave Cramer |
|---|---|
| Тема | Re: Guidance on avoiding session pinning with psqlODBC and RDS Proxy |
| Дата | |
| Msg-id | CADK3HH+5m8dnkGGPjADz35t68hT79xWTo5YEjpCbZfbMLwpjPw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Guidance on avoiding session pinning with psqlODBC and RDS Proxy (Dave Cramer <davecramer@postgres.rocks>) |
| Ответы |
RE: Guidance on avoiding session pinning with psqlODBC and RDS Proxy
|
| Список | pgsql-odbc |
Hi Neeta,I'm curious why RDSProxy is pinning on this. I can't think of any reason to pin on a SHOWThat said, I'm equally curious why psqlODBC is doing it, it doesn't really need to know the transaction isolation levelDave Cramerwww.postgres.rocksOn 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 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 = 'ISO';
SET extra_float_digits = 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’s 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 still 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 LLP (A limited liability partnership with LLP Identification Number: AAI-6901 effective 28th Feb 2017)
В списке pgsql-odbc по дате отправления: