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>
 <CAA4eK1LN+T1pLfGBxDW-gps5h-YX6FAjRwkKaV2wwQDDVdi6fw@mail.gmail.com>
In-Reply-To: <CAA4eK1LN+T1pLfGBxDW-gps5h-YX6FAjRwkKaV2wwQDDVdi6fw@mail.gmail.com>
From: shveta malik <shveta.malik@gmail.com>
Date: Wed, 11 Feb 2026 17:09:26 +0530
Message-ID: <CAJpy0uBm7m5AFgg6xgWB6msGrivusoDe7PKg9XKHYm_JYQnegg@mail.gmail.com>
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
To: Amit Kapila <amit.kapila16@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>, 
	shveta malik <shveta.malik@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAJpy0uBm7m5AFgg6xgWB6msGrivusoDe7PKg9XKHYm_JYQnegg%40mail.gmail.com>
Precedence: bulk

On Wed, Feb 11, 2026 at 3:41=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.co=
m> wrote:
>
> On Wed, Feb 4, 2026 at 11:32=E2=80=AFAM shveta malik <shveta.malik@gmail.=
com> wrote:
> >
> > On Wed, Feb 4, 2026 at 12:38=E2=80=AFAM Heikki Linnakangas <hlinnaka@ik=
i.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 bette=
r 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 on=
ly
> > 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.

Okay, yes. So I am okay with it. The slight change I suggested (if to
else-if) and a comment will make it more clean.

>
> > > It has one user-visible
> > > effect: If you call the function with acquired_pid !=3D 0 and the ori=
gin
> > > 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, b=
ut
> > > I think the new behavior is slightly better. The fact that the origin=
 is
> > > 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.
>
> --
> With Regards,
> Amit Kapila.