Re: [Patch] add new parameter to pg_replication_origin_session_setup - Mailing list pgsql-hackers

On Tue, Dec 23, 2025 at 2:24 PM 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 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

thanks
Shveta