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);
--Check pg_replication_slots:
slot_name | failover | synced | active | inactive_timeout
---------------+----------+--------+--------+------------------
logical_slot1 | t | t | f | 900
--Run sync function
SELECT pg_sync_replication_slots();
--check again, inactive_timeout is set back to primary's value.
slot_name | failover | synced | active | inactive_timeout
---------------+----------+--------+--------+------------------
logical_slot1 | t | t | f | 120
====================
I feel altering synced slot's inactive_timeout should be prohibited on
standby. It should be in sync with primary always. Thoughts?
I am listing the concerns raised by me:
1) create-subscription with create_slot=false overwriting
inactive_timeout of existing slot ([1])
2) last_inactive_time set for synced slots may result in invalidation
of slot on promotion. ([2])
3) alter replication slot to alter inactive_timout for synced slots on
standby, should this be allowed?
[1]:
https://www.postgresql.org/message-id/CAJpy0uAqBi%2BGbNn2ngJ-A_Z905CD3ss896bqY2ACUjGiF1Gkng%40mail.gmail.com
[2]:
https://www.postgresql.org/message-id/CAJpy0uCLu%2BmqAwAMum%3DpXE9YYsy0BE7hOSw_Wno5vjwpFY%3D63g%40mail.gmail.com
thanks
Shveta
