[PATCH] libpq: try all addresses for a host before moving to next on target_session_attrs mismatch

Incremental Analysis: Evgeny's Rebuttal on getaddrinfo() Reliability and DNS Client Concerns

Evgeny returns after an 11-day pause with a carefully researched counter-argument to Jacob Champion's position that getaddrinfo() cannot be relied upon to return complete address lists.

New Technical Arguments

1. Distinguishing "not specified" from "will lose data"

Evgeny concedes Jacob's point that POSIX does not specify getaddrinfo() as a DNS RRset API, but argues this doesn't mean it will arbitrarily drop DNS answers in practice. He draws a critical distinction:

• getaddrinfo() is not a DNS API by specification ✓ (agreed)
• getaddrinfo() will normally lose arbitrary DNS answers ✗ (does not follow)

He backs this with implementation analysis: Linux libc implementations expose the full usable RRset unless there's an explicit policy reason not to (AI_ADDRCONFIG, address family filtering, etc.).

2. DNS protocol guarantees against partial results

Evgeny cites RFC 1035 (TC bit truncation handling) and RFC 1123 §6.1.3.2 (mandatory TCP retry on truncation) to argue that a conforming resolver stack will not silently deliver partial RRsets to libc. This addresses Jacob's concern about POSIX not guaranteeing all records — Evgeny argues the guarantee comes from DNS protocol semantics, not POSIX.

3. Legitimate omission cases are already policy-sensitive

The cases where getaddrinfo() does omit addresses (mixed IPv4/v6, AI_ADDRCONFIG, v4mapped, resolver policy, non-DNS NSS sources) are themselves explicit policy decisions, not random data loss. This reframes the concern: the "missing addresses" scenario isn't a reliability problem but a deliberate system policy that libpq should respect anyway.

4. Introducing a DNS client inside libpq creates worse problems

This is Evgeny's strongest new argument against Jacob's SVCB/SRV proposal. A libpq-internal DNS client would bypass the system resolver path, breaking or changing behavior for:

• /etc/hosts
• nsswitch.conf
• mDNS
• LDAP integration
• systemd-resolved policy
• Split DNS
• VPN-specific resolver routing
• Container/runtime-specific resolution

Evgeny frames this as trading "a relatively narrow theoretical weakness in the getaddrinfo() contract for a much broader compatibility and behavioral change in existing deployments."

Strategic Framing

This message shifts the debate from "is the current approach theoretically correct?" to "which approach has lower operational risk?" Evgeny is arguing that the pragmatic solution (iterating addresses from getaddrinfo) is more operationally safe than the architecturally "pure" solution (SVCB via custom DNS resolution), because it stays within the existing Unix networking contract that users and infrastructure already depend on.