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.
> 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.
```
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.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
v5-0001-Fix-unintended-drop-of-active-replication-origins.patch
Description: v5-0001-Fix-unintended-drop-of-active-replication-origins.patch
