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>
In-Reply-To: <e0508305-bc6a-417c-b969-36564d632f9e@iki.fi>
From: shveta malik <shveta.malik@gmail.com>
Date: Wed, 4 Feb 2026 11:32:29 +0530
Message-ID: <CAJpy0uD5T692uyaRr0GKqd1eLHW55A0=MH-V8tRPicTxDqMu=g@mail.gmail.com>
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Amit Kapila <amit.kapila16@gmail.com>, 
	"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/CAJpy0uD5T692uyaRr0GKqd1eLHW55A0%3DMH-V8tRPicTxDqMu%3Dg%40mail.gmail.com>
Precedence: bulk

On Wed, Feb 4, 2026 at 12:38=E2=80=AFAM Heikki Linnakangas <hlinnaka@iki.fi=
> wrote:
>
> The new error message is not great:
>
> postgres=3D# select pg_replication_origin_session_setup('myorigin', 12345=
678);
> ERROR:  could not find replication state slot for replication origin
> with OID 1 which was acquired by 12345678
>
> Firstly, replication origin is not an OID. Secondly, it's a little
> confusing because the "replication state slot" is in fact present.
> However, it's currently inactive, i.e. not "acquired" by the given PID.
>
> I propose to change that to:
>
> postgres=3D# select pg_replication_origin_session_setup('myorigin', 12345=
678);
> ERROR:  replication origin with ID 1 is not active for PID 12345678
>
> That's more in line with this neighboring message:
>
> ERROR:  replication origin with ID 1 is already active for PID 701228

Thank You for your suggestions here. The suggested error message looks
better. Thus patch001 LGTM.

>
> I also wonder if the error code is appropriate. That error uses
> ERRCODE_OBJECT_IN_USE, but if the problem is that the origin is
> currently *not* active, that seems backwards. I didn't change that in
> the attached patch, but it's something to think about.

I agree that ERRCODE_OBJECT_IN_USE doesn=E2=80=99t seem like the best fit i=
n
below code. IMO, ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE would be
more suitable.But let's hear from others.

if (curstate->acquired_by !=3D acquired_by)
{
ereport(ERROR,
(errcode(ERRCODE_OBJECT_IN_USE),
errmsg("replication origin with ID %d is not active for PID %d",
curstate->roident, acquired_by)));
}

>
> 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?

> It has one user-visible
> effect: If you call the function with acquired_pid !=3D 0 and the origin
> 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 is
> inactive feels like the bigger problem here.

I am okay with this change though. Let's see what others have to say.

thanks
Shveta