On Mon, Mar 25, 2024 at 2:40 PM shveta malik <shveta.ma...@gmail.com> wrote:
>
> On Mon, Mar 25, 2024 at 1:37 PM Bertrand Drouvot
> <bertranddrouvot...@gmail.com> wrote:
> >
> > Hi,
> >
> > Yeah, and I can see last_inactive_time is moving on the standby (while not
> > the
> > case on the primary), probably due to the sync worker slot
> > acquisition/release
> > which does not seem right.
> >
>
> Yes, you are right, last_inactive_time keeps on moving for synced
> slots on standby. Once I disabled slot-sync worker, then it is
> constant. Then it only changes if I call pg_sync_replication_slots().
>
> On a different note, I noticed that we allow altering
> inactive_timeout for synced-slots on standby. And again overwrite it
> with the primary's value in the next sync cycle. Steps:
>
> ====================
> --Check pg_replication_slots for synced slot on standby, inactive_timeout is
> 120
> slot_name | failover | synced | active | inactive_timeout
> ---------------+----------+--------+--------+------------------
> logical_slot1 | t | t | f | 120
>
> --Alter on standby
> SELECT 'alter' FROM pg_alter_replication_slot('logical_slot1', 900);
>
I think we should keep pg_alter_replication_slot() as the last
priority among the remaining patches for this release. Let's try to
first finish the primary functionality of inactive_timeout patch.
Otherwise, I agree that the problem reported by you should be fixed.
--
With Regards,
Amit Kapila.
