MIME-Version: 1.0
References: <CAMPB6wfe4zLjJL8jiZV5kjjpwBM2=rTRme0UCL7Ra4L8MTVdOg@mail.gmail.com>
 <b9666b93-093b-4c9f-a385-772d6ab5688c@app.fastmail.com> <CAMPB6we7+97L72Ru0=WxMDi24xMbZgr2B8Nwoo5i=r=UNuG_gQ@mail.gmail.com>
 <a4ee2198-5309-4b6f-90ef-c08b45a2f572@app.fastmail.com> <CAA4eK1JfPPFTmz7mUk26zPH8+qH9UBpkquxw75x7Ngx_D_6XXQ@mail.gmail.com>
 <CAMPB6wfgvWjSvKNPoJkRqaL46geRDoL++Pt_3Czc2QNAdpVQHw@mail.gmail.com>
 <CAA4eK1JC6yB6q52qEZ5dLNWRUEZoO-aa_XKBZ3_mcb=V2z7zug@mail.gmail.com>
 <CAMPB6weUqU6P2w5VUGVSLKWcvU1AQHmW+7O9qc9yD4CB5kEYVA@mail.gmail.com>
 <CAA4eK1Lm_W5j3DPj6PDSTyodGu87QgxpNwwsi-wVR0+B1FSOoA@mail.gmail.com>
 <CAMPB6wckvkKrXVPH5j8Ske2cVedkb-TRLdnOb5e74zYM1CynGw@mail.gmail.com>
 <CAA4eK1+NDjprcKvr0p2GDMTCs9yxFCY41bOd+6avqAm2n+TXdQ@mail.gmail.com>
 <CAMPB6wdc10tc7gpVXG75r51M41zVSabip9Lz7hssWEtyhecWww@mail.gmail.com>
 <OSCPR01MB14966201F1DCB853145912FF1F53DA@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <CAMPB6wcOWBURHB1igRgCjD3geAemdoATfkKByMwrMM1TgMN64w@mail.gmail.com>
 <OSCPR01MB14966BF4CA9B767C259DBD9CDF53EA@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <CAMPB6wdtKZLEeZ7UW=DYmXWv8Y=uVGrDqXTMhT19Z4VTzo3cfg@mail.gmail.com>
 <CAA4eK1LHVd8wQzauWgeEV436L7btrCfujPH1sR196sY_Mp8zYA@mail.gmail.com>
 <CAMPB6wdPtjbR93oB1XJtYkRtTR64BJG4o5a+0DSSez=puuyuGA@mail.gmail.com>
 <OSCPR01MB14966FC456D053AB00A2EB278F514A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <CAA4eK1++mHd-SsHyJd2ZB26F7kCz--LbtjQLuQ0h3z9mcYK-AQ@mail.gmail.com>
 <OS7PR01MB149681B14B2432A9CEA7A3586F517A@OS7PR01MB14968.jpnprd01.prod.outlook.com>
 <OSCPR01MB14966F65DE462D0A479B8ADD6F516A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <CAA4eK1LeyzuiRPZB+o7mO0pB6_=tpkjoum5Hj+t1SYydS4K2kQ@mail.gmail.com>
 <OSCPR01MB14966B68C2148C1BC462AA906F516A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <TY4PR01MB169077EE72ABE9E55BAF162D494B5A@TY4PR01MB16907.jpnprd01.prod.outlook.com>
 <CAJpy0uAcd4BuRGJT0_Xojjtn7w6uiWhAY3Xv=C2GqXoUxeOrYw@mail.gmail.com>
In-Reply-To: <CAJpy0uAcd4BuRGJT0_Xojjtn7w6uiWhAY3Xv=C2GqXoUxeOrYw@mail.gmail.com>
From: shveta malik <shveta.malik@gmail.com>
Date: Mon, 5 Jan 2026 16:00:15 +0530
Message-ID: <CAJpy0uCH=z+x8Rb9U+DCE8=4=7UiG6P_yXoPxGLfp_Nuz5jPfw@mail.gmail.com>
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Amit Kapila <amit.kapila16@gmail.com>, 
	Doruk Yilmaz <doruk@mixrank.com>, 
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, 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/CAJpy0uCH%3Dz%2Bx8Rb9U%2BDCE8%3D4%3D7UiG6P_yXoPxGLfp_Nuz5jPfw%40mail.gmail.com>
Precedence: bulk

On Mon, Jan 5, 2026 at 3:15=E2=80=AFPM shveta malik <shveta.malik@gmail.com=
> wrote:
>
> On Tue, Dec 23, 2025 at 2:24=E2=80=AFPM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> >
> > Hi,
> >
> > When testing the new parameter in pg_replication_origin_session_setup()=
, I
> > noticed a bug allowing the origin in use to be dropped. The issue arise=
s when
> > two backends set up the same origin; if the second backend resets the o=
rigin
> > first, it resets the acquired_by flag regardless of whether the first b=
ackend is
> > using it. This allows the origin to be dropped, enabling the slot in sh=
ared
> > memory to be reused, which is unintended.
> >
> > About the fix, simply adding a check for acquired_by field does not wor=
k,
> > because if the first backend resets the origin first, it still risks be=
ing
> > dropped while second backend uses it.
> >
> > To fully resolve this, I tried to add a reference count (refcount) for =
the
> > origin. The count is incremented when a backend sets up the origin and
> > decremented upon a reset. As a result, the replication origin is only d=
ropped
> > when the reference count reaches zero.
> >
> > Thanks to Kuroda-San for discussing and reviewing this patch off-list.
> >
>
> Thanks Hou-San and Kuroda-San.
>
> What should be the expected behavior when Session1 resets the origin
> (changing acquired_pid from its own PID to 0), while Session2 is
> already connected to the origin and Session3 also attempts to reuse
> the same origin?
>
> Currently it asserts:
>
> Session1:
> select pg_replication_origin_create('origin');
> SELECT pg_replication_origin_session_setup('origin');
>
> Session2:
> SELECT pg_replication_origin_session_setup('origin',48028);
>
> Session1:
> SELECT pg_replication_origin_session_reset();
>
> Session3:
> SELECT pg_replication_origin_session_setup('origin');
> This asserts at:
> TRAP: failed Assert("session_replication_state->refcount =3D=3D 0"), File=
:
> "origin.c", Line: 1231, PID: 48037
>

I checked the behavior on HEAD. Session3 is able to set up the origin
and sets its own PID in acquired_pid. But it is unclear to me which
PID should be recorded in acquired_pid - Session2=E2=80=99s PID, since it s=
et
up the origin earlier, or Session3=E2=80=99s PID. Or does this even make an=
y
difference?

I found one more related issue on HEAD, sharing it here:

When the first backend creates and sets up the origin, followed by a
second backend setting it up, and then the first backend resets it
while the second backend attempts to drop it, an assertion is
triggered:
TRAP: failed Assert("session_replication_state->roident !=3D
InvalidRepOriginId"), File: "origin.c", Line: 1257, PID: 48438

thanks
Shveta