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 1wQrfv-001vti-0c for pgsql-hackers@arkaria.postgresql.org; Sat, 23 May 2026 19:06:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wQrfs-00G8JN-2R for pgsql-hackers@arkaria.postgresql.org; Sat, 23 May 2026 19:06:17 +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 1wQrfs-00G8J9-13 for pgsql-hackers@lists.postgresql.org; Sat, 23 May 2026 19:06:17 +0000 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wQrfq-000000015QU-144p for pgsql-hackers@lists.postgresql.org; Sat, 23 May 2026 19:06:16 +0000 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-49040362e4aso25928655e9.0 for ; Sat, 23 May 2026 12:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hudson-trading.com; s=google-20201111; t=1779563173; x=1780167973; darn=lists.postgresql.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=rKsynPfnsKd0ISVbDbK0hFu0QeoW9EAwkmCJMZkZbC8=; b=A6qHMIcP3nyxcv7856BjlbjjTU5PENzUQEimmUtK6KeGVziihs4j9+KDpQxTOA5F+Z DL0KNBD4oh/w9+QbDWsEMebJNMwN2oTs9yQsREfODRy7X29riUejtdsDhQomzkCYkTAO ziQ/Pu6RIlOWBzVYdhCD4WSPnW+xnbvKIqHCenJf4p+LIzGFcGyjL5nprKzq1vqV0qmZ YCT0LIzube3UJ0A00BF1xsRZvTDfjQpEMK8PrfzR8DsPRA4ncnLNGXFGq178yeK3evLC RlDwS5aI/ij1sgfgBJCEnFsyXcvRI+7pPbe52LmseR4iGwhdHwaLivVcYH1LI7lWRJf8 0VHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779563173; x=1780167973; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=rKsynPfnsKd0ISVbDbK0hFu0QeoW9EAwkmCJMZkZbC8=; b=rMS0KDl5uyaiDaI85qy/R4YusdF8XNAVr+XAqRs91UuYdj+hS/wzXf8W631ZQOvsTW EvwVLBEeppQIKDDINh6AiRByRM3Ywyuqo2M+Qu1+JkGMwD5KVSOQSzj6565Nm7MxlaEj xjWYVkisPNFzZigfyI87p7BdGWRq8eOSx+zrvdXFT/SLwttG6mXrWUNxSpIBaWEIOx2J 3vJBNYuNOdsF4zzzCE9xnsEA6b1tcIuhys8TPwu5Pjkp+lqhxp8LGRZLmi6ApOdk6SUM 2eRsGXekUvugwShrL5hZ0nh/C9AlP0E6VMSQrUld//h84OXVBME8fHEh05bNzmYLx0Zx 5bCA== X-Forwarded-Encrypted: i=1; AFNElJ9//ANtX8AaHglMpt+dX0wQPVFQgRwW3dDczHNqu/yLT5uqAR2Ho4tjQUzfsZZdwFjMTbvhuaEwGD1fk0h/@lists.postgresql.org X-Gm-Message-State: AOJu0Yxq+1aZCnNAxGuWBX3zhskVx1bsxfeTkkGQvIAEYu6ftU9t5Sn/ zKU5TrgNWbuurK2KhaGoQS3afCCUZwbS3OygIoL980HSAENazf82SeEsk/IOob3ckv3p5kWj2Dv F1lEZyMO+PvBEbuPTkxKhoWh8dyX+a75ZqypGlIuUb3G3AdRL0MMC8WalD1lhdeZOqLqzZW0G0A UGW+HfJ4ZHK/3wJ3mhOGxorkp8rcWWzeEGRD5Pa21cBzEQ8/b6qO4/xZfXa5rUrivDYxJtvQ== X-Gm-Gg: Acq92OGqJyCtykG3PHaPW5pP72f5sXLzlBHWrfWF3N2SNoWi3SceKh2DvVDoa2M4Qi9 EkYuVZzFK4nijmZlSZKvHgZiEjYv5tNXeqfxj2Dzd+aYTgcScD/B/VjDEACAfXkz3pw0LRvuUm6 /MvCBV+K8XsPk1hPvTzkRd2D9AiHvK7Y6jmCgEuU8ity3prLJNA5+vIqn1fz9he/lcF3+kR4uU0 16sABLk95psYlPhOWg0zn0xZHNDI+hpeGXxsxJHfBZ3tcJTGEIxqRMNQQHZ9YNMpRdQVOlC/ocm jM6kilOXiIg+Pw/Sfcw8sjiyIQXsoJxD1ugpNPNGTTJxyBwofDyr1WdTvHyWTVeR0TFMH8oPc+o lD3YGhly4JUUbfeVzhOp1PJ8hA5YhLsABXhmQXW50JyaprTlgxktmaP8OXrP1h8f6guqyt8s5BQ XTnP8jcjUhSNCQaU+ndNTuqrFJarGq5m7zdS9BloHOH1UpHjz7nu0Jrxx7AAnC X-Received: by 2002:a05:600c:3393:b0:490:4b89:5375 with SMTP id 5b1f17b1804b1-4904b89553dmr52473225e9.10.1779563172194; Sat, 23 May 2026 12:06:12 -0700 (PDT) Received: from smtpclient.apple ([31.94.26.222]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490428ec538sm43905525e9.23.2026.05.23.12.06.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 May 2026 12:06:10 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-2EE2A27B-89C9-4471-A9F0-603FDB870DB9 Content-Transfer-Encoding: 7bit From: Evgeny Kuzin Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] libpq: try all addresses for a host before moving to next on target_session_attrs mismatch Date: Sat, 23 May 2026 12:05:58 -0700 Message-Id: <41F87F28-F5CD-4ADB-B4D3-33A39927CBAF@hudson-trading.com> References: Cc: Andrew Jackson , pgsql-hackers , Evgeny Kuzin , Laurenz Albe , Tom Lane , pgsql-hackers@lists.postgresql.org In-Reply-To: To: Jacob Champion X-Mailer: iPhone Mail (23E261) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail-2EE2A27B-89C9-4471-A9F0-603FDB870DB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I spent some more time digging into this to make sure I was not overlooking s= omething fundamental in the resolver behavior here. I agree that POSIX does not specify getaddrinfo() as a dns rrset api. It is a= socket address selection api, and the specification leaves room for address= family filtering, ordering, mapped addresses, AI_ADDRCONFIG, and other syst= em policy decisions [1]. But I think there is an important distinction between: - getaddrinfo() is not specified to preserve exact DNS semantics - getaddrinfo() will normally lose arbitrary dns answers The second conclusion does not seem to follow from the first one. In the specific A/AAAA case discussed here, the linux libc implementations I= checked generally do expose the full usable RRset returned by the resolver u= nless there is an explicit policy reason not to (AI_ADDRCONFIG, v4mapped han= dling, requested address family, resolver policy, etc). This behavior is also consistent with dns resolver semantics themselves. Rfc= 1035 defines truncation handling via the TC bit, and rfc1123 requires retryi= ng over tcp when truncation occurs [2][3]. In the ordinary dns case, I would= therefore not expect a conforming resolver stack to silently hand libc an a= rbitrary partial RRset. The cases where getaddrinfo() may legitimately omit addresses are mostly the= same cases where connection behavior is already policy-sensitive anyway: - mixed ipv4/v6 environments - AI_ADDRCONFIG filtering - v4mapped handling - resolver policy rules - non dns nss sources Those are not really random losses of dns data. They are explicit host resol= ution and connectivity policy decisions. What concerns me more about introducing a dns client inside libpq is that we= would no longer be following the same resolver path as the rest of the syst= em. That is user-visible behavior, not merely an implementation detail. For example, it risks bypassing or changing behavior around: - /etc/hosts - nsswitch.conf - mdns - ldap integration - systemd-resolved policy - split dns - vpn-specific resolver routing - container/runtime-specific resolution The current behavior may not be theoretically perfect from a dns abstraction= perspective, but it is operationally well-understood and consistent with ex= isting unix networking expectations. My concern is that we may be trading a relatively narrow theoretical weaknes= s in the getaddrinfo() contract for a much broader compatibility and behavio= ral change in existing deployments. [1] https://pubs.opengroup.org/onlinepubs/9799919799/functions/getaddrinfo.h= tml [2] https://datatracker.ietf.org/doc/html/rfc1035 [3] https://datatracker.ietf.org/doc/html/rfc1123#section-6.1.3.2= --Apple-Mail-2EE2A27B-89C9-4471-A9F0-603FDB870DB9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I spent some more time digging into this to make sure I w= as not overlooking something fundamental in the resolver behavior here.


I agree t= hat POSIX does not specify getaddrinfo() as a dns rrset api. It is a socket a= ddress selection api, and the specification leaves room for address family f= iltering, ordering, mapped addresses, AI_ADDRCONFIG, and other system policy= decisions [1].


But I think there is an important distinction between:

<= p class=3D"p2" style=3D"margin: 0px; font-width: normal; font-size: medium; l= ine-height: normal; font-size-adjust: none; font-kerning: auto; font-variant= -alternates: normal; font-variant-ligatures: normal; font-variant-numeric: n= ormal; font-variant-east-asian: normal; font-variant-position: normal; font-= feature-settings: normal; font-optical-sizing: auto; font-variation-settings= : normal; min-height: 21px; -webkit-text-size-adjust: auto;">

- getaddrinfo()= is not specified to preserve exact DNS semantics

- g= etaddrinfo() will normally lose arbitrary dns answers


The second conclusion does n= ot seem to follow from the first one.


In the specific A/AAAA case discussed here, t= he linux libc implementations I checked generally do expose the full usable R= Rset returned by the resolver unless there is an explicit policy reason not t= o (AI_ADDRCONFIG, v4mapped handling, requested address family, resolver poli= cy, etc).


This behavior is also consistent with dns resolver semantics themselves.= Rfc1035 defines truncation handling via the TC bit, and rfc1123 requires re= trying over tcp when truncation occurs [2][3]. In the ordinary dns case, I w= ould therefore not expect a conforming resolver stack to silently hand libc a= n arbitrary partial RRset.


The cases where getaddrinfo() may legitimately omit a= ddresses are mostly the same cases where connection behavior is already poli= cy-sensitive anyway:


<= /p>

- mixed ipv4/v6 environments

- AI_A= DDRCONFIG filtering

- v4mapped handling

- resolver policy rules

- non dns nss sou= rces



What concerns me more about introducin= g a dns client inside libpq is that we would no longer be following the same= resolver path as the rest of the system. That is user-visible behavior, not= merely an implementation detail.


For example, it risks bypassing or changing be= havior around:


- /etc/hosts

- nsswitch.conf

- mdns

- ldap integration

- systemd-resolved policy

- split dns

- vpn-specific resolver routing

-= container/runtime-specific resolution


The current behavior may not be theoretic= ally perfect from a dns abstraction perspective, but it is operationally wel= l-understood and consistent with existing unix networking expectations.


My concer= n is that we may be trading a relatively narrow theoretical weakness in the g= etaddrinfo() contract for a much broader compatibility and behavioral change= in existing deployments.

<= br>

[1] https://pubs.opengroup.org/onlinepubs/9799919799/func= tions/getaddrinfo.html

[2] https://datatracker.ietf= .org/doc/html/rfc1035

[3] https://datatracker.ietf.= org/doc/html/rfc1123#section-6.1.3.2

= --Apple-Mail-2EE2A27B-89C9-4471-A9F0-603FDB870DB9--