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 1vyBEx-00HW6Q-0T for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Mar 2026 16:07:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vyBEv-000JuJ-1X for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Mar 2026 16:07:53 +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 1vyBEv-000JuB-0B for pgsql-hackers@lists.postgresql.org; Thu, 05 Mar 2026 16:07:53 +0000 Received: from mail-westeuropeazolkn19011024.outbound.protection.outlook.com ([52.103.33.24] helo=AS8PR04CU009.outbound.protection.outlook.com) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vyBEt-00000000xbB-0Rdj for pgsql-hackers@postgresql.org; Thu, 05 Mar 2026 16:07:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QvYKjo3gg7stQJDqET4fmbLgvv2V6CsQrfdH0WGhBkVZYq1TfG9d5fqKtESMBqQCJBpkqHoIQi+CXd4mfJ2oYtM6cslrsab6t3ydFkMHERsXy4RxErZLHPhFNhY6BlxaMsUI5JOHKEBpkh8Hww3JnA7LGtO9ybtkUfftkLhsTlXnhsaVs+3k3GZycrccZ5fQLE6z9sSYoFz17B0LQ3KMjnwCm0OOCZmGoxIlH7nxjVWGyT35UrlhnUXkMvRRdAQBGPf+5tr3qU4W7g8oijZoVTP3MRLoq1e656Oo4hCA59ZvNUKdVibiSDyrEQZtbuKL+cVVg4umUUu+/ZB5FQGSwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=srlRtddLxn03ajzT1Xlgem08yFmHV6b07ARsvJ0d/+s=; b=J8R5icjV8QYR+Xee9Fays1u1hxYoYdRSmj+/nkCEhTxOI+v4deCPJkaBtGkGoTc4pEkMoAusn87XYuM6aEHwY9aBG1cteRoRvtH46dxYT/prvstaexhxCLNeJ8MdEeyDcMZ/fxwMXYnPluQzek7Ih7AtweJISwTiS4bcEBKAIxkCjJk8FQ2WqviggsuItj3HDAzFVu9CTuaseDJK1ffXaIsBVdGwcMdplCVMhU4ojyJsevoZCkbXwgUgjmu76wcIkRRxV9YnJ9j5UT252cG0siDrVwPy7Ni/r8vRZHAgsDF/NFsFMCsjNMus4yV4MUN6YI28Qgv8usZNXhJRo3NDfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=srlRtddLxn03ajzT1Xlgem08yFmHV6b07ARsvJ0d/+s=; b=RuI4pQBBUVredBlNDTkmtNbuaPk0Ejd9O5Sh7JHYlAhTHmEdBOebTqzvfVILnRBBn7PzBm2YUehwhxBm8qaw/j2K0TWSn1kJ69zFNixzpKrW/E7MjD0GeKnzC7YwRW34DtEqO6iVmdTmB4zDRrMUuCo7KX34yPHZFAQIImAcYue+bNMZTbV/gOxjeTWWOHnFRAUi0zcwjnzehUSN8JuWpqzNJeB+4oAy/Pf9Sc+MDwvchdmKzQ5CGCd/isTgXfq47J05JqybPcHfFsednt2vA18spnWNpUNVKns7tAFpe8sGkD40Uvgx1uxm4dKe3Vay2In2YiRY6ymTQY4ZBO/6aw== Received: from AM9PR09MB4900.eurprd09.prod.outlook.com (2603:10a6:20b:30e::18) by GV2PR09MB6014.eurprd09.prod.outlook.com (2603:10a6:150:c0::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9678.17; Thu, 5 Mar 2026 16:07:47 +0000 Received: from AM9PR09MB4900.eurprd09.prod.outlook.com ([fe80::7853:fb25:6a8a:4a3d]) by AM9PR09MB4900.eurprd09.prod.outlook.com ([fe80::7853:fb25:6a8a:4a3d%6]) with mapi id 15.20.9678.017; Thu, 5 Mar 2026 16:07:47 +0000 From: Evgeny Kuzin To: Andrew Jackson , "pgsql-hackers@postgresql.org" Subject: Re: Add Option To Check All Addresses For Matching target_session_attr Thread-Topic: Add Option To Check All Addresses For Matching target_session_attr Thread-Index: AQHcrLm8IqBVn13MUEm3A5KusvqstrWgGmxn Date: Thu, 5 Mar 2026 16:07:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AM9PR09MB4900:EE_|GV2PR09MB6014:EE_ x-ms-office365-filtering-correlation-id: 4ab0a657-212e-47a7-2174-08de7ad15802 x-microsoft-antispam: BCL:0;ARA:14566002|15080799012|15030799006|8060799015|19110799012|12050799012|9400799043|8062599012|41001999006|22091999003|461199028|39105399006|25031999004|7071999006|20031999003|31061999003|55001999003|12121999013|24121999003|10035399007|4302099013|3412199025|440099028|102099032|3340999064|13041999003|1602099012|40105399003; x-microsoft-antispam-message-info: =?us-ascii?Q?9NmiLqwcf9T75ZmLcbanvcoqhggUEgex2fqRN977dZQADkblOe9HTBdCwrkc?= =?us-ascii?Q?B1d7xZU4ut/lb3y4fozNUkmT0CCRHQ6SJsgxbQN2UnvCLbS/MDePe0NRA2CL?= =?us-ascii?Q?aDSKGq/rlCpTbscJfGpMfa7MjSaFRmCaYx3EuekIBzOTtgKjSlDuK3qevDHk?= =?us-ascii?Q?XViFpy0jWRwlOaoPtDXXM+uUKrT9t/BzSFHJcBYkOwDyu/xw2dxUV4JHCVnC?= =?us-ascii?Q?5V2CvsORlpRWS/vSSWN1X/BvPrNL7pnIV+7f17++fNMm1/d+ZSZjgZoZcZMe?= =?us-ascii?Q?wypbzTofnpOR95ZSsUTAbUsSl/wQnsCMZGh4EqTe7iV4NGTOH+7CTAf/g7TH?= =?us-ascii?Q?Ld2EYWSl8i9XYy9vXaDWsrL/KmrkJUr8mwqOkJqYc9ZzGho/u4ftJYb8whsU?= =?us-ascii?Q?FGM9jpc3gKXV1uxW/Loy5onC8Gtp8gtaKNBt6h/Nz613neGEU7GtYMTukqul?= =?us-ascii?Q?HFt0XNLIKcOObwkh9i7yLHb4PooNJTRORwF8xeSxnxAM1udkly64F7QnUoy7?= =?us-ascii?Q?g7ee/UdPEDmSBROmb/adeNuhCPUDEQlxGdIe5flAwzz0UsoFRffGzKZPCF3b?= =?us-ascii?Q?aHIgtwXrqJ8Ett45nOZUzFvqLKY/bZjLexIBFqGNDutXMvUmlR9/MWVfZrYG?= =?us-ascii?Q?bC0zwNRVwYwQsVwjomMaKNdBHxj4Gb2LSBwB516rsehjpJBUDmg6l37b6zoz?= =?us-ascii?Q?d2gvw8L3jkcUavXus+r3oy+FMHXTb43P6mMeDtfzS3iAAaWPdaz2FBbwB8dR?= =?us-ascii?Q?rBErQfM9rD3HFUJcrMMhtHO3JILNKbrf+v72Jm1Wz1yl6zHFVMYXR8nSS/NJ?= =?us-ascii?Q?6Hu3Ut7NtlZTo6U3St/9v2axJjhFRfQrPC/CpTpPNI8qp9qZJGqolhsg82Ji?= =?us-ascii?Q?pY9KRrNiZbW6jV3TtRh63je1zvw/8OcIvhWR5BfFfIIuLIYXRP5OUry56WnY?= =?us-ascii?Q?L21ofirr48/H83ZGVEwGPuAm4Ut259NXT50355+svaSLT9+PhMCgpKQ+kJ8C?= =?us-ascii?Q?LkKeOnazeYNzpRFRKNpJbXOgTCWN1Y2ODL+zAYJdIwssmoJrGYp/yVtrJeGR?= =?us-ascii?Q?n22FfV9U/iaERc7uruL3EbYTkNdy50Fpg1Rb1KbH+kEHdsOJjHlc8Uhn85XH?= =?us-ascii?Q?5erqqK479SLE5lMAFP8fsn9hkfGDTSNUpG/gxn5BljQJhnlKIcO7egXH7F0L?= =?us-ascii?Q?sVgSHiVjM/4qDOQFNSqS/WyzAOCGpDBC+VLGWSVGczwcrsftcuenHZiEi+fE?= =?us-ascii?Q?uMfitSx5mKpZN2FVuqi+yNhy+kkFdr4ueEHABzPCYCJ8D+TDwBDvO7RIO9y2?= =?us-ascii?Q?0JCvXcG7SHIFXd6rVG2qw9zdgMH4qTfMze0fsTdnlwtAHSZSb9KpvccrsKYk?= =?us-ascii?Q?icL3RIA=3D?= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?IQHtPJAaAngYO5J6T7k8DrpyGFQ8SQDFOp0WCdIMpAw12kZ80h1wKOJq4tRb?= =?us-ascii?Q?k0cMuUSoYdZjqik863eaiU79ZufLxhs+bVZjTIq0Xs8cChp+W1XVd0ShuUlo?= =?us-ascii?Q?egHOOL68RHaWbsNY/viIHbz8LhWZLtgoJl2wkiN3z75o+OlNYTjjyICd1jcE?= =?us-ascii?Q?tTLi8pJ/qZtO6KAWLTQqNsUzTRsen3Itr6VPMiGDB1YzwYTEQEYL3xLMze/e?= =?us-ascii?Q?NhPJg6xq/2CATOOe85+igIfA8L4NPcq07JSmYhr5bxnXEnzHABm93z/IGh9p?= =?us-ascii?Q?dCg+gXWB97HE1wszf6jiukqe/PDPsvDaKRMs8cUwSZy/fa6wYSAdfWtqQpOQ?= =?us-ascii?Q?ioO33CGULaJoLSPSOSWvjYQoUUbKM54mIa5hA6p9iK9DwXtyPa1bA23VzF2/?= =?us-ascii?Q?3Fp+8aCgk4TB/0e0v+2aSZBPauxdulstpNzB4VEm7Gi8cXXmWhQsYgkDVxsH?= =?us-ascii?Q?E6sWxmbYrEBuyF93bcyFoemXLWz6wu9gse0ed6rB4ICthtWjyEv5BiUX6Hbq?= =?us-ascii?Q?wXRC2Bv9QuVxSmABek+m+pbFiCOrf4tw8N0be8KAS5pJv6QMR7kmkpF8aJfo?= =?us-ascii?Q?nWIL17eyWhGhsVMLVGKZtWgmkSh4fUg5nXCRe9FFldEoamR6wKYIakVHiyOX?= =?us-ascii?Q?NTOFrz/cigBqvlBoI0E3DMnMLTTYCahJcvLSgEE3Kn1sc9oiMX1oWopvkF7i?= =?us-ascii?Q?Qa0VHNH3ZHMfQ5tJMXRogMl8UzamnqDfvr4ERyVpxs18XrEcQGiCae7VE3gZ?= =?us-ascii?Q?iRpie2l8jGP2K/twAaTr6uJz4rLqsvg8JNVDsIa0SgqHMMrQPhRr+lovpxLM?= =?us-ascii?Q?+oWMxKabCeK+3K7ZvEEfNAalCaQM2G4bW/yIOD+CabBR/wur8oeJRnhV72No?= =?us-ascii?Q?n7TzmtWpL4xewdDBo9v+jCSxGwEXLmqW0B1qYUSoKkBVctezdkgMaMM3n7xA?= =?us-ascii?Q?0kA1VmsFI6U604cBtIhfNZ8jPBgVKYjOhT6bnCbdPBEKNHJLyslGczHi5R+u?= =?us-ascii?Q?oWhKqh3Je2XwBVVrzFX0Kex08cOcUX4+/N6oq6GfdJw+5z7XCWA7IMX1l1Cl?= =?us-ascii?Q?IL/ZgomSJcLB04l3Mak1CBipwKzcjl6YKlAfZtVwHrq67aRU4rfK7B9r4T7a?= =?us-ascii?Q?sXm+T/BIWnZhsScSa5sGxIS0vp1ULx37oy5qETy0J18dt29r4HY3l7un5b7R?= =?us-ascii?Q?iWPjb4rtdyMuqCQKlOZ7hSBm8hVwPxxXPQT2YFcbBVXmBeOe6xxDM9oVzifW?= =?us-ascii?Q?C5uzUP7Qr2JzLGRpSfjqMBnoO9GqovG68gbj0G5IWGyWCSXv4nKKPEj3fBcf?= =?us-ascii?Q?BM4B9hDGr9cwZwr4AE4itE9Z1N4uIeVE/DzmQg9MekFuZ21DswWUrh2DhIdd?= =?us-ascii?Q?tO90Xl2D4ILJqRf4oPZeHcDIz4HJ?= Content-Type: multipart/alternative; boundary="_000_AM9PR09MB49001B8EE023E0ADB715549E977DAAM9PR09MB4900eurp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4900.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 4ab0a657-212e-47a7-2174-08de7ad15802 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2026 16:07:47.6311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR09MB6014 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_AM9PR09MB49001B8EE023E0ADB715549E977DAAM9PR09MB4900eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI! I just submitted a patch [1] addressing the same problem from a different a= ngle. I wasn't aware of this earlier work until Andrey pointed me to it. My patch takes a simpler approach: instead of adding a new check_all_addrs = parameter, it just changes try_next_host to try_next_addr in the target_ses= sion_attrs mismatch handling (~12 lines changed). The rationale being that = Artem's point about documentation seems valid - the docs already say "all t= he hosts and addresses will be tried in order, until one succeeds." The cur= rent skip-to-next-host behavior appears to contradict this. I'm happy to coordinate - the core question seems to be: 1. Behavioral fix (my approach) - aligns with existing documentation, si= mpler 2. Opt-in parameter (your approach) - preserves backward compatibility e= xplicitly What do you think? If the community prefers backward compatibility via an e= xplicit option, I could withdraw my patch in favor of yours. If the consens= us is that this is actually a bug fix per the docs, perhaps the simpler cha= nge is better. [1] https://www.postgresql.org/message-id/AM9PR09MB49008B02CDF003054D5D4E00= 977DA@AM9PR09MB4900.eurprd09.prod.outlook.com Thanks, Evgeny ________________________________ From: Andrew Jackson Sent: Wednesday, November 20, 2024 3:51 PM To: pgsql-hackers@postgresql.org Subject: Add Option To Check All Addresses For Matching target_session_attr Hi, I was attempting to set up a high availability system using DNS and target_= session_attrs. I was using a DNS setup similar to below and was trying to u= se the connection strings `psql postgresql://user@pg.database.com/db_name?t= arget_session=3Dread-write` to have clients dynamically connect to the primary or `p= sql postgresql://user@pg.database.com/db_name?target_session=3Dread-only` to have cli= ents connect to a read replica. The problem that I found with this setup is that if libpq is unable to get = a matching target_session_attr on the first connection attempt it does not = consider any further addresses for the given host. This patch is designed t= o provide an option that allows libpq to look at additional addresses for a= given host if the target_session_attr check fails for previous addresses. Would appreciate any feedback on the applicability/relevancy of the goal he= re or the implementation. Example DNS setup ________________________________ Name | Type | Record ______________|______|___________ pg.database.com | A | ip_address_1 pg.database.com | A | ip_address_2 pg.database.com | A | ip_address_3 pg.database.com | A | ip_address_4 --_000_AM9PR09MB49001B8EE023E0ADB715549E977DAAM9PR09MB4900eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI!
I just submitted a patch [1] addressing the same problem from a different a= ngle. I wasn't aware of this earlier work until Andrey pointed me to it.
My patch takes a simpler approach: instead of adding a new check_all_addrs par= ameter, it just changes try_next_host to try_next_addr in th= e target_session_attrs mismatch handling (~12 lines changed). The rationale being that Artem's po= int about documentation seems valid - the docs already say "all the ho= sts and addresses will be tried in order, until one succeeds." The cur= rent skip-to-next-host behavior appears to contradict this.
I'm happy to coordinate - the core question seems to be:
  1. Behavioral fix (my approach) - aligns with existing documentati= on, simpler
  2. Opt-in parameter (your approach) - preserves backward compatibi= lity explicitly
What do you think? If the community prefers backward compatibility via an e= xplicit option, I could withdraw my patch in favor of yours. If the consens= us is that this is actually a bug fix per the docs, perhaps the simpler cha= nge is better.
[1] https://www.postgresql.org/message-id/AM9PR09MB49008B02CDF003054D5D4E00= 977DA@AM9PR09MB4900.eurprd09.prod.outlook.com
Thanks,
Evgeny


From: Andrew Jackson <an= drewjackson947@gmail.com>
Sent: Wednesday, November 20, 2024 3:51 PM
To: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>= ;
Subject: Add Option To Check All Addresses For Matching target_sessi= on_attr
 
Hi,

I was attempting to set up a high availability system using DNS and ta= rget_session_attrs. I was using a DNS setup similar to below and was trying= to use the connection strings `psql postgresql://user@pg.database.com/db= _name?target_session=3Dread-write` to have clients dynamically connect to the primary or `psql postgresql://<= a href=3D"http://user@pg.database.com/db_name?target_session=3Dread-only`">= user@pg.database.com/db_name?target_session=3Dread-only` to have c= lients connect to a read replica. 

The problem that I found with this setup is that if libpq is unable to= get a matching target_session_attr on the first connection attempt it does= not consider any further addresses for the given host. This patch is desig= ned to provide an option that allows libpq to look at additional addresses for a given host if the target_= session_attr check fails for previous addresses.

Would appreciate any feedback on the applicability/relevancy of the go= al here or the implementation.
 
Example DNS setup
________________________________
Name                  | T= ype    | Record
______________|______|___________
pg.database.com | A   = ;     | ip_address_1
pg.database.com | A   = ;     | ip_address_2
pg.database.com | A   = ;     | ip_address_3
pg.database.com | A   = ;     | ip_address_4
--_000_AM9PR09MB49001B8EE023E0ADB715549E977DAAM9PR09MB4900eurp_--