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
