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 1vyOwO-0005C6-39 for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Mar 2026 06:45:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vyOvM-0036WV-2u for pgsql-hackers@arkaria.postgresql.org; Fri, 06 Mar 2026 06:44:37 +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 1vyOvM-0036WM-1X for pgsql-hackers@lists.postgresql.org; Fri, 06 Mar 2026 06:44:37 +0000 Received: from forwardcorp1a.mail.yandex.net ([2a02:6b8:c0e:500:1:45:d181:df01]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vyOvK-000000018gB-17tO for pgsql-hackers@postgresql.org; Fri, 06 Mar 2026 06:44:36 +0000 Received: from mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net [IPv6:2a02:6b8:c1f:3a87:0:640:845c:0]) by forwardcorp1a.mail.yandex.net (Yandex) with ESMTPS id 67203C015A; Fri, 06 Mar 2026 09:44:32 +0300 (MSK) Received: from smtpclient.apple (unknown [2a02:6bf:8080:879::1:1e]) by mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id Uij36U0A9mI0-oSSr8cYf; Fri, 06 Mar 2026 09:44:31 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1772779471; bh=QTRwtyZFAqII+AAS8JY6vgRhWbGR77OGRH/l2pWjr3w=; h=References:To:Cc:In-Reply-To:Date:From:Message-Id:Subject; b=UKQIx2PGOgxVfBuuFzDgjqpyoYVZtuDNHLnWa7R8fl9gp4lkul8D85g+BlJaI5Wv6 h+Gs4bg1SqKPXyG+P6E0YxOhShdFGHXailajxOSaVdcoH0XkS9U0KXbauGy1ik+iXi CTlsv2zljsCUnd0N587vN4ohHCe5+9pSO2iMG5AM= Authentication-Results: mail-nwsmtp-smtp-corp-main-69.vla.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Andrey Borodin Message-Id: <817CE6D9-C5E3-4625-B001-4515C72A1DD8@yandex-team.ru> Content-Type: multipart/mixed; boundary="Apple-Mail=_81011C1F-7E90-4DBF-8676-9005F0D8443B" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: Add Option To Check All Addresses For Matching target_session_attr Date: Fri, 6 Mar 2026 11:44:20 +0500 In-Reply-To: Cc: Navrotskiy Artem , Vladimir Sitnikov , Dave Page , pgsql-hackers , Evgeny Kuzin To: Andrew Jackson References: <235381750793454@mail.yandex.ru> X-Mailer: Apple Mail (2.3864.300.41.1.7) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_81011C1F-7E90-4DBF-8676-9005F0D8443B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Aug 2025, at 04:43, Andrew Jackson = wrote: >=20 > Attached is the rebased patch. I've took a look into the patch again. The behavior and integration with the connection state machine look = correct,=20 and the tests + docs are in good shape. Some notes: 1. Use a dedicated default "0" for check_all_addrs (not = DefaultLoadBalanceHosts, this one is used for load balancing, need more "0"). 2. Guard the two strcmp(conn->check_all_addrs, "1") uses so they are = safe when conn->check_all_addrs is NULL. 3. Fix the test typos in 008 (standby_expeect_traffic and the three = =E2=80=9Con node1=E2=80=9D messages). 4. Parse check_all_addrs once into a bool (like load_balance_type) and = use that in the connection path for consistency and clarity. Now about important part: is the name "check_all_addrs" good? I've asked LLM after explaining it what the feature does. PFA attached = output. Personally, I like "try_all_addrs". It's a bit unclear to me how randomization (load balancing) on different addresses should work. Best regards, Andrey Borodin. --Apple-Mail=_81011C1F-7E90-4DBF-8676-9005F0D8443B Content-Disposition: attachment; filename=check_all_addrs_variations.txt Content-Type: text/plain; x-unix-mode=0644; name="check_all_addrs_variations.txt" Content-Transfer-Encoding: quoted-printable On naming and how to configure the feature: What the option does It only matters when target_session_attrs is set. On a = target_session_attrs mismatch (e.g. we wanted primary but got standby), it controls: 0 (default): treat this host as failed and move to the next host. 1: stay on this host and try the next address for the same hostname. So the name is really answering: on session-attrs mismatch, try next = address vs next host? Is "check_all_addrs" good? Pros: Short, easy to type, and the env var PGCHECKALLADDRS is clear. Cons: It doesn't mention target_session_attrs, so the link to that feature isn't obvious. "Check" is vague (check for what?). The important part is "try all addresses (for this host) on mismatch." With only check_all_addrs=3D1 in the conninfo, someone might not guess it's about session attrs. So it's usable but not ideal. Naming alternatives try_all_addrs Shorter; "try" is more accurate than "check". Still doesn't tie to target_session_attrs. try_next_addr_on_mismatch Very clear. Long; "mismatch" is a bit generic. target_session_attrs_try_all_addrs Explicitly tied to the feature. Too long for conninfo. session_attrs_try_all_addrs Shorter, still linked to session attrs. Slightly ambiguous ("try all" what?). try_all_host_addrs Makes "addresses of current host" clear. Doesn't mention session attrs. A reasonable compromise is try_all_addrs: same length as now, clearer = verb, and the docs can state it applies when target_session_attrs is used. If = you want the link to session attrs in the name, session_attrs_try_all_addrs = is the next best, at the cost of length. Other ways to configure it 1) No new option (behavioral change only) Evgeny's approach: always try next address on session-attrs mismatch. No naming issue, but it changes default behavior and was argued against for backward compatibility. 2) Fold into target_session_attrs E.g. target_session_attrs=3Dread-write,try_all_addrs or = read-write+try_all. Pro: option is clearly scoped to that feature. Con: one parameter does = two things (desired role + connection strategy); parsing and docs get more complex. 3) Keep a separate option (current design) A dedicated connection parameter that only has effect when target_session_attrs is set. Pro: simple parsing, clear in conninfo, = easy to document. Con: the name should make the "only with = target_session_attrs" contract obvious (in name or docs). 4) Tie to load_balance_hosts E.g. when load_balance_hosts=3Drandom (or disable) and = target_session_attrs is set, add a third mode like try_all_addrs. Con: mixes two concepts = (load balancing vs which address to try next on mismatch); semantics get confusing. Recommendation Naming: Prefer try_all_addrs over check_all_addrs (clearer, same = length). If you want the link to session attrs in the name, use = session_attrs_try_all_addrs and accept the length. Configuration: Keeping a separate connection parameter is the right = design; the main improvement is the name and a one-line note in the docs that it = only has effect when target_session_attrs is set. I wouldn't fold it into target_session_attrs or into load_balance_hosts. Made with Cursor.= --Apple-Mail=_81011C1F-7E90-4DBF-8676-9005F0D8443B--