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> <CAJpy0uCH=z+x8Rb9U+DCE8=4=7UiG6P_yXoPxGLfp_Nuz5jPfw@mail.gmail.com>
In-Reply-To: <CAJpy0uCH=z+x8Rb9U+DCE8=4=7UiG6P_yXoPxGLfp_Nuz5jPfw@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Fri, 9 Jan 2026 14:30:47 +0530
Message-ID: <CAA4eK1KkqQD88Td53v6Z=adGSMLR7wN543WhqccOW17ykt-QDg@mail.gmail.com>
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
To: shveta malik <shveta.malik@gmail.com>
Cc: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, 
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Doruk Yilmaz <doruk@mixrank.com>, 
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAA4eK1KkqQD88Td53v6Z%3DadGSMLR7wN543WhqccOW17ykt-QDg%40mail.gmail.com>
Precedence: bulk

On Mon, Jan 5, 2026 at 4:00=E2=80=AFPM shveta malik <shveta.malik@gmail.com=
> wrote:
>
> On Mon, Jan 5, 2026 at 3:15=E2=80=AFPM shveta malik <shveta.malik@gmail.c=
om> 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 ari=
ses when
> > > two backends set up the same origin; if the second backend resets the=
 origin
> > > first, it resets the acquired_by flag regardless of whether the first=
 backend is
> > > using it. This allows the origin to be dropped, enabling the slot in =
shared
> > > memory to be reused, which is unintended.
> > >
> > > About the fix, simply adding a check for acquired_by field does not w=
ork,
> > > because if the first backend resets the origin first, it still risks =
being
> > > dropped while second backend uses it.
> > >
> > > To fully resolve this, I tried to add a reference count (refcount) fo=
r the
> > > origin. The count is incremented when a backend sets up the origin an=
d
> > > decremented upon a reset. As a result, the replication origin is only=
 dropped
> > > 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"), Fi=
le:
> > "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=
 set
> up the origin earlier, or Session3=E2=80=99s PID. Or does this even make =
any
> 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
>

Can we address these problems by prohibiting leader worker to reset
when pa workers are still associated with the origin? The way for
leader to know if pa workers are associated with origin is by checking
following condition: acquired_by =3D=3D MyProcpid AND refcount > 1.

--=20
With Regards,
Amit Kapila.