public inbox for [email protected]
help / color / mirror / Atom feedFrom: shveta malik <[email protected]>
To: Zhijie Hou (Fujitsu) <[email protected]>
Cc: Hayato Kuroda (Fujitsu) <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Doruk Yilmaz <[email protected]>
Cc: [email protected] <[email protected]>
Cc: shveta malik <[email protected]>
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
Date: Mon, 5 Jan 2026 16:00:15 +0530
Message-ID: <CAJpy0uCH=z+x8Rb9U+DCE8=4=7UiG6P_yXoPxGLfp_Nuz5jPfw@mail.gmail.com> (raw)
In-Reply-To: <CAJpy0uAcd4BuRGJT0_Xojjtn7w6uiWhAY3Xv=C2GqXoUxeOrYw@mail.gmail.com>
References: <CAMPB6wfe4zLjJL8jiZV5kjjpwBM2=rTRme0UCL7Ra4L8MTVdOg@mail.gmail.com>
<[email protected]>
<CAMPB6we7+97L72Ru0=WxMDi24xMbZgr2B8Nwoo5i=r=UNuG_gQ@mail.gmail.com>
<[email protected]>
<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>
On Mon, Jan 5, 2026 at 3:15 PM shveta malik <[email protected]> wrote:
>
> On Tue, Dec 23, 2025 at 2:24 PM Zhijie Hou (Fujitsu)
> <[email protected]> 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 arises 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 work,
> > 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) 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 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 == 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’s PID, since it set
up the origin earlier, or Session3’s 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 !=
InvalidRepOriginId"), File: "origin.c", Line: 1257, PID: 48438
thanks
Shveta
view thread (43+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
In-Reply-To: <CAJpy0uCH=z+x8Rb9U+DCE8=4=7UiG6P_yXoPxGLfp_Nuz5jPfw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox