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.94.2) (envelope-from ) id 1v3Cvn-00D69l-Mz for pgpool-hackers@arkaria.postgresql.org; Mon, 29 Sep 2025 12:24:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v3Cvl-000qwl-EZ for pgpool-hackers@arkaria.postgresql.org; Mon, 29 Sep 2025 12:24:38 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v3Cvl-000qwd-3W for pgpool-hackers@lists.postgresql.org; Mon, 29 Sep 2025 12:24:37 +0000 Received: from mail-yx1-xb12c.google.com ([2607:f8b0:4864:20::b12c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v3Cvi-000VKc-1j for pgpool-hackers@lists.postgresql.org; Mon, 29 Sep 2025 12:24:36 +0000 Received: by mail-yx1-xb12c.google.com with SMTP id 956f58d0204a3-635283199a9so3175750d50.1 for ; Mon, 29 Sep 2025 05:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tailorbrands.com; s=google; t=1759148674; x=1759753474; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gA5CejO0MtVP1TGV2ylci8niad3Z42leHwqMPz6oPO8=; b=XyzWk+tVBOAWnqLohEjfZvdqQWuhPNiaql1LAxHCrWLLG5ZTVeSvGoBD9o5PMnC4F3 oirG0+u5PDzPYfyt3GOten0oNUsfT/QLvz2TqeIHbFmEuxHBO+cSiW2xrWG07VEXdhkE FT/DmqQfQe+HZXMHQ06FR0EHMIZx8fDEnUQMdpgtn68tXJCWh/o7DXCccSBgTiqmFDHe Ofa4VcVtDa8dUm/whz/g3bfJgLMa5ZTjLuA04nmGE6QRY/Q4naiQOTk0ocZRVNU47VIt E+Qq6RZgqXRdn8K+Sp48MCc2fVDQ1ImsCUZyupGVlPfzprqE/tR7n8VTIEWFyrYPIpCx x9aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759148674; x=1759753474; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gA5CejO0MtVP1TGV2ylci8niad3Z42leHwqMPz6oPO8=; b=YP7IzzukraBGq4kp+/CGi0g+Ujee50LfaZbb/MMEPxeFa+1foDifXDNIYCyNg+7Uxt K+kVzO6efFSuQVAWV69NrVsEnjIx0CO4d+a+v9OKXJSt0P3dBjMlB9o2AVazCKukzNNx MgBPpWbB78hiz+5JjQUrPTtfaBedM0AZQGYGPDyURLxO9lE0opoMkbHvpituVtWq4MN1 dwQQrgU9BlpjKha18omnyHOXjR2WiuYf6qeWAApOw0NtAxestKZoDnQ9RCdTLd7vsmUs c8zEEDGVxqrtnzNbyuf2Bd2f7SXJE0Uefg4w5rUGnH6fNo8okloIENiuSl1FRmgHjPc2 6ziA== X-Gm-Message-State: AOJu0YzB5GNfVtY+djdxq6CrvAJHp8c65imemamMlH5m5CV+HZXfs79N qN4zydQsHfIr6nku4TCdnxNwVfPw6HOcxGVDZIix5wQodyDEWqqCh005OSP83PC/6pcBwFO/KfU SpxxRdpIDgOvqTVJzVOjQwEbR4CcgS3uEe+fkxM0sf2HdH5OtMCd4FxuFfuWAdI4= X-Gm-Gg: ASbGncu0arV8LUXskFSYUFEph3S2KHMxcrPcinOZwL0MlZbFUyEafLp3VU4+Dy77ifE ALQOe397DXgMLGG/6D3dqIxdV8N05UTRqobBf9oM1JPyQ1SPeayOHpv9t+z51LjoYkN5LO2zSQy Ke7AEetWDxo7TRu108LHcwOp0/gGWnjXIhL9aSjX6cduECIUCHx7mhP4hxCiSzu0xucyu636QAf VfD X-Google-Smtp-Source: AGHT+IFy4stEqdj7ljirBE5g3DlbLuskjYPTKVufr0dLXf9dYztlHTSQ7eh0slk7AXfzb304MfgaDa2MzLRrimF6NWE= X-Received: by 2002:a53:e44a:0:b0:633:a1c7:ab72 with SMTP id 956f58d0204a3-6361a876c1emr14373157d50.37.1759148673686; Mon, 29 Sep 2025 05:24:33 -0700 (PDT) MIME-Version: 1.0 References: <20250916.193012.1767059551833136064.ishii@postgresql.org> <534F5F0C-708B-4DBB-AD98-101E324E5361@tailorbrands.com> <20250922.073400.794497598091925011.ishii@postgresql.org> In-Reply-To: <20250922.073400.794497598091925011.ishii@postgresql.org> From: Nadav Shatz Date: Mon, 29 Sep 2025 21:24:22 +0900 X-Gm-Features: AS18NWC8MU-IB8UDIlPWry1rYYdYlyhKg__UHmGXmOrjku9t3SFSdPmmVuXnjbo Message-ID: Subject: Re: Proposal: recent access based routing for primary-replica setups To: Tatsuo Ishii Cc: pgpool-hackers@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000cd91b2063fefb765" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000cd91b2063fefb765 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would actually suggest including down state instances in case pgpool isn=E2=80=99t aware yet. It can exclude them once it does. For these cases maybe -1 ? Nadav Shatz Tailor Brands | CTO On Mon, Sep 22, 2025 at 7:34=E2=80=AFAM Tatsuo Ishii = wrote: > > Thank you for the kind words. We are having a great time! > > Glad to hear that! > > > Regarding the command knowing about the primary I think it is safe to > assume. > > Okay. > > > We can start this way and evolve in the future if needed. > > Agreed. > > > I can include a note about it in the notes that the command will only > receive the secondary instances as arguments. > > > > Anything else that comes to mind? > > Sounds like a reasonable requirement. Also the command excludes any > instance which is in down state? > > Best regards, > -- > Tatsuo Ishii > SRA OSS K.K. > English: http://www.sraoss.co.jp/index_en/ > Japanese:http://www.sraoss.co.jp > > > Nadav Shatz > > CTO > > > >> On Sep 16, 2025, at 7:30=E2=80=AFPM, Tatsuo Ishii wrote: > >> > >> =EF=BB=BF > >>> > >>> Hi Tatsuo, > >>> > >>> Sorry for the late reply - I'm traveling with my family at the moment > (in > >>> Japan actually) > >> > >> Excellent! Hope you and your family are spending great time in Japan. > >> > >>> and might be delayed in responding. > >> > >> No problem at all. I think you should focus on the travel at this > >> moment. > >> > >>> Re your points: > >>> 1 - we can, but I have to say that a user I tend to prefer > configuration > >>> values not have a "magic" value that does something different than th= e > >>> usual case like this would create. I'd stick with what we already hav= e > >>> planned. happy to hear from others on the mailing list as well of > course. > >> > >> Makes sense. I withdraw my proposal. > >> > >>> 2 - I think we can have the primary always be the first or we can > >>> completely remove it since it might be redundant as it's always going > to be > >>> 0. what do you think? > >> > >> What I am not sure is, whether we can assume the command always knows > >> which host (or IP) is primary? If the answer is yes, then we could > >> omit the primary. What do you think? > >> > >>> 3 - I agree with you, next version (after we clear everything else) > will > >>> have only ip/hostname+port. > >> > >> Thank you for understanding. > >> > >>> Let me know your thoughts > >>> > >>> Thanks! > >>> > >>>> On Tue, Sep 9, 2025 at 9:42=E2=80=AFAM Tatsuo Ishii > wrote: > >>>> > >>>> Hi Nadav, > >>>> > >>>>> Hi Tatsuo, > >>>>> > >>>>> Please find attached the 3 patch files (implementation, tests, docs= ) > with > >>>>> the updates we discussed. > >>>>> > >>>>> What do you think? > >>>> > >>>> I haven't read the code details yet but I have a few questions. > >>>> > >>>> 1) Can we use only replication_delay_source_cmd and if it's value is > >>>> 'builtin', then we treat it as replication_delay_source =3D builti= n? > >>>> Maybe this is matter of taste but I would like to know your > >>>> opinion. > >>>> > >>>> 2) replication_delay_source_cmd will be given an ordered list of > >>>> instance identifiers. But it seems there's no way for the command > >>>> which one is the primary instance. Is it okay for the command? > >>>> > >>>> 3) Why do you have 3 kind of instance identifiers (application name, > >>>> hostname (IP) + port and node id? I thought "hostname (IP) + port" > >>>> is sufficient. > >>>> > >>>> Comments? > >>>> -- > >>>> Tatsuo Ishii > >>>> SRA OSS K.K. > >>>> English: http://www.sraoss.co.jp/index_en/ > >>>> Japanese:http://www.sraoss.co.jp > >>>> > >>> > >>> > >>> -- > >>> Nadav Shatz > >>> Tailor Brands | CTO > > > > > --000000000000cd91b2063fefb765 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would actually suggest including down state instances i= n case pgpool isn=E2=80=99t aware yet. It can exclude them once it does.=C2= =A0
For these cases maybe =C2=A0-1 ?

Nad= av Shatz
Tail= or Brands=C2=A0| CTO
=


On Mon, Sep 22, 2025 at 7:34=E2=80=AFAM= Tatsuo Ishii <ishii@postgresql.= org> wrote:
> Thank you for the kind wo= rds. We are having a great time!

Glad to hear that!

> Regarding the command knowing about the primary I think it is safe to = assume.

Okay.

> We can start this way and evolve in the future if needed.

Agreed.

> I can include a note about it in the notes that the command will only = receive the secondary instances as arguments.
>
> Anything else that comes to mind?

Sounds like a reasonable requirement. Also the command excludes any
instance which is in down state?

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

> Nadav Shatz
> CTO
>
>> On Sep 16, 2025, at 7:30=E2=80=AFPM, Tatsuo Ishii <ishii@postgresql.org> = wrote:
>>
>> =EF=BB=BF
>>>
>>> Hi Tatsuo,
>>>
>>> Sorry for the late reply - I'm traveling with my family at= the moment (in
>>> Japan actually)
>>
>> Excellent! Hope you and your family are spending great time in Jap= an.
>>
>>> and might be delayed in responding.
>>
>> No problem at all. I think you should focus on the travel at this<= br> >> moment.
>>
>>> Re your points:
>>> 1 - we can, but I have to say that a user I tend to prefer con= figuration
>>> values not have a "magic" value that does something = different than the
>>> usual case like this would create. I'd stick with what we = already have
>>> planned. happy to hear from others on the mailing list as well= of course.
>>
>> Makes sense. I withdraw my proposal.
>>
>>> 2 - I think we can have the primary always be the first or we = can
>>> completely remove it since it might be redundant as it's a= lways going to be
>>> 0. what do you think?
>>
>> What I am not sure is, whether we can assume the command always kn= ows
>> which host (or IP) is primary? If the answer is yes, then we could=
>> omit the primary. What do you think?
>>
>>> 3 - I agree with you, next version (after we clear everything = else) will
>>> have only ip/hostname+port.
>>
>> Thank you for understanding.
>>
>>> Let me know your thoughts
>>>
>>> Thanks!
>>>
>>>> On Tue, Sep 9, 2025 at 9:42=E2=80=AFAM Tatsuo Ishii <ishii@postgresql.or= g> wrote:
>>>>
>>>> Hi Nadav,
>>>>
>>>>> Hi Tatsuo,
>>>>>
>>>>> Please find attached the 3 patch files (implementation= , tests, docs) with
>>>>> the updates we discussed.
>>>>>
>>>>> What do you think?
>>>>
>>>> I haven't read the code details yet but I have a few q= uestions.
>>>>
>>>> 1) Can we use only replication_delay_source_cmd and if it&= #39;s value is
>>>>=C2=A0 =C2=A0'builtin', then we treat it as replica= tion_delay_source =3D builtin?
>>>>=C2=A0 =C2=A0Maybe this is matter of taste but I would like= to know your
>>>>=C2=A0 =C2=A0opinion.
>>>>
>>>> 2) replication_delay_source_cmd will be given an ordered l= ist of
>>>>=C2=A0 =C2=A0instance identifiers. But it seems there's= no way for the command
>>>>=C2=A0 =C2=A0which one is the primary instance. Is it okay = for the command?
>>>>
>>>> 3) Why do you have 3 kind of instance identifiers (applica= tion name,
>>>>=C2=A0 =C2=A0hostname (IP) + port and node id? I thought &q= uot;hostname (IP) + port"
>>>>=C2=A0 =C2=A0is sufficient.
>>>>
>>>> Comments?
>>>> --
>>>> Tatsuo Ishii
>>>> SRA OSS K.K.
>>>> English: http://www.sraoss.co.jp/index_en/
>>>> Japanese:http://www.sraoss.co.jp
>>>>
>>>
>>>
>>> --
>>> Nadav Shatz
>>> Tailor Brands | CTO
>
>
--000000000000cd91b2063fefb765--