On Wed, Jan 14, 2026 at 9:13 AM Hayato Kuroda (Fujitsu)
<[email protected]> wrote:
>
> Dear Shveta,
>
> > 1)
> > +step s1_reset: SELECT pg_replication_origin_session_reset();
> >
> > After the above step, please add a step to attempt dropping the
> > replication origin. The original issue was that once s1 releases the
> > origin, it becomes eligible for dropping, so the test should
> > explicitly verify this behavior.
>
> I think it is bit difficult because pg_replication_origin_drop() has PID in 
> the
> ERROR message. Also, this patch prevents first process resets the origin, 
> i.e.,
> the exact same situation won't happen anymore. Not fixed.
>

Okay.

> > 2)
> > Also before the above step, please add a step where s0 tries to reset
> > the origin while s1 is still acquiring it. It is needed to cover the
> > path where s0 should fail to release origin.
>
> The step has already existed, see below.
>

Okay, sorry I missed it somehow.

> ```
> step s0_reset: SELECT pg_replication_origin_session_reset();
> ERROR:  cannot reset replication origin with ID 1 because it is still in use 
> by other processes
> step s1_reset: SELECT pg_replication_origin_session_reset();
> pg_replication_origin_session_reset
> -----------------------------------
>
> (1 row)
> ```
>
> Others are corrected and adjusted by me, see the attached.
> 0001 and 0002 are combined because no one claimed them.
>

Thanks. The patch LGTM.

thanks
Shveta


Reply via email to