MIME-Version: 1.0
References: <CAJpy0uB19aKEgVgh8gwzj87NUyDgOf01boa-6xJZK+nhb=3W4g@mail.gmail.com>
 <CAA4eK1+h4mOvRqRaGfUtSgZuBhzWWmrBcY3jQ4DDV=cEJ4dwnQ@mail.gmail.com>
 <TY7PR01MB145543A74547443E49E4993E7F58EA@TY7PR01MB14554.jpnprd01.prod.outlook.com>
 <CAJpy0uD6D294d=Hq4oROmtKAew5DfKERNxs=DsAwUFBFF2kERg@mail.gmail.com>
 <TY7PR01MB14554FB7D02601425DE3752DEF58FA@TY7PR01MB14554.jpnprd01.prod.outlook.com>
 <CAA4eK1JvYROk5usAX0Uy=00VACB=w1rvUcyoKvRuke5EMfmi3Q@mail.gmail.com>
 <e0508305-bc6a-417c-b969-36564d632f9e@iki.fi> <CAJpy0uD5T692uyaRr0GKqd1eLHW55A0=MH-V8tRPicTxDqMu=g@mail.gmail.com>
In-Reply-To: <CAJpy0uD5T692uyaRr0GKqd1eLHW55A0=MH-V8tRPicTxDqMu=g@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Wed, 11 Feb 2026 15:40:50 +0530
Message-ID: <CAA4eK1LN+T1pLfGBxDW-gps5h-YX6FAjRwkKaV2wwQDDVdi6fw@mail.gmail.com>
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
To: shveta malik <shveta.malik@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, 
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, 
	"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Doruk Yilmaz <doruk@mixrank.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAA4eK1LN%2BT1pLfGBxDW-gps5h-YX6FAjRwkKaV2wwQDDVdi6fw%40mail.gmail.com>
Precedence: bulk

On Wed, Feb 4, 2026 at 11:32=E2=80=AFAM shveta malik <shveta.malik@gmail.co=
m> wrote:
>
> On Wed, Feb 4, 2026 at 12:38=E2=80=AFAM Heikki Linnakangas <hlinnaka@iki.=
fi> wrote:
> >
>
> >
> > The second patch rearranges the if-else statements to check those
> > conditions. I found the current logic hard to follow, this makes them
> > feel more natural, in my opinion at least.
>
> I=E2=80=99m not fully convinced that it makes the code clearer or better =
to
> understand. For example, consider the following error case:
>
> else if (curstate->acquired_by =3D=3D 0 && curstate->refcount > 0)
>     ereport(ERROR,
>             (errcode(ERRCODE_OBJECT_IN_USE),
>              errmsg("replication origin with ID %d is already active
> in another process",
>                     curstate->roident)));
>
>
> The condition was self explanatory earlier. The condition has now been
> rewritten (or reduced) to:
> if (acquired_by =3D=3D 0 && curstate->refcount > 0)
>
> However, this is not exactly the same as the earlier logic. On closer
> inspection, the condition 'curstate->acquired_by =3D=3D 0', while no
> longer stated explicitly, was implicitly guaranteed by the preceding
> error block:
>
> if (curstate->acquired_by !=3D 0)
>     ERROR;
>
> One way to make this clearer would be to structure the logic as:
>
> if (curstate->acquired_by !=3D 0)
>     ERROR;
> else if (curstate->refcount > 0)
>     ERROR;
>
> Even then, it is still not clear why this error (the case where
> curstate->refcount > 0 and curstate->acquired_by =3D=3D 0) is raised only
> when acquired_by =3D=3D 0, or how the same situation is expected to be
> handled when acquired_by !=3D 0. The earlier code was clearer in this
> regard (at least to me), as it first handled the
> 'curstate->acquired_by !=3D acquired_by' case, making the overall logic
> somehow easier to understand. Perhaps we can try by adding a comment
> or restructure in some other way if possible and needed?
>

I see your point but one advantage with the proposed code change is
that it started to appear that we can extend this part of code easily
in the future as it separates most of the handling related to when a
user has given acquired_by parameter's value as zero and non-zero.

> > It has one user-visible
> > effect: If you call the function with acquired_pid !=3D 0 and the origi=
n
> > has no state slot, *and* there are no free slots, you previously got
> > this error:
> >
> > postgres=3D# select pg_replication_origin_session_setup('other', 123);
> > ERROR:  could not find free replication state slot for replication
> > origin with ID 2
> > HINT:  Increase "max_active_replication_origins" and try again.
> >
> > Now you get this:
> >
> > postgres=3D# select pg_replication_origin_session_setup('other', 123);
> > ERROR:  cannot use PID 123 for inactive replication origin with ID 2
> >
> > Both error messages are more or less appropriate in that situation, but
> > I think the new behavior is slightly better. The fact that the origin i=
s
> > inactive feels like the bigger problem here.
>
> I am okay with this change though. Let's see what others have to say.
>

Either message is fine with me in this situation.

--=20
With Regards,
Amit Kapila.