Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Nadav Shatz <nadav@tailorbrands.com>
Mime-Version: 1.0 (1.0)
Subject: Re: Proposal: recent access based routing for primary-replica setups
Date: Sun, 21 Sep 2025 08:57:34 +0900
Message-Id: <534F5F0C-708B-4DBB-AD98-101E324E5361@tailorbrands.com>
References: <20250916.193012.1767059551833136064.ishii@postgresql.org>
Cc: pgpool-hackers@lists.postgresql.org
In-Reply-To: <20250916.193012.1767059551833136064.ishii@postgresql.org>
To: Tatsuo Ishii <ishii@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/534F5F0C-708B-4DBB-AD98-101E324E5361%40tailorbrands.com>
Precedence: bulk

Thank you for the kind words. We are having a great time!

Regarding the command knowing about the primary I think it is safe to assume=
. We can start this way and evolve in the future if needed. I can include a n=
ote about it in the notes that the command will only receive the secondary i=
nstances as arguments.

Anything else that comes to mind?
=20
Nadav Shatz
CTO

> On Sep 16, 2025, at 7:30=E2=80=AFPM, Tatsuo Ishii <ishii@postgresql.org> w=
rote:
>=20
> =EF=BB=BF
>>=20
>> Hi Tatsuo,
>>=20
>> Sorry for the late reply - I'm traveling with my family at the moment (in=

>> Japan actually)
>=20
> Excellent! Hope you and your family are spending great time in Japan.
>=20
>> and might be delayed in responding.
>=20
> No problem at all. I think you should focus on the travel at this
> moment.
>=20
>> 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 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.=

>=20
> Makes sense. I withdraw my proposal.
>=20
>> 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 b=
e
>> 0. what do you think?
>=20
> 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?
>=20
>> 3 - I agree with you, next version (after we clear everything else) will
>> have only ip/hostname+port.
>=20
> Thank you for understanding.
>=20
>> Let me know your thoughts
>>=20
>> Thanks!
>>=20
>>> On Tue, Sep 9, 2025 at 9:42=E2=80=AFAM Tatsuo Ishii <ishii@postgresql.or=
g> wrote:
>>>=20
>>> Hi Nadav,
>>>=20
>>>> Hi Tatsuo,
>>>>=20
>>>> Please find attached the 3 patch files (implementation, tests, docs) wi=
th
>>>> the updates we discussed.
>>>>=20
>>>> What do you think?
>>>=20
>>> I haven't read the code details yet but I have a few questions.
>>>=20
>>> 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 builtin?
>>>   Maybe this is matter of taste but I would like to know your
>>>   opinion.
>>>=20
>>> 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?
>>>=20
>>> 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.
>>>=20
>>> Comments?
>>> --
>>> Tatsuo Ishii
>>> SRA OSS K.K.
>>> English: http://www.sraoss.co.jp/index_en/
>>> Japanese:http://www.sraoss.co.jp
>>>=20
>>=20
>>=20
>> --
>> Nadav Shatz
>> Tailor Brands | CTO