On Mon, Mar 25, 2024 at 1:37 PM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > > > > I have one concern, for synced slots on standby, how do we disallow > > > invalidation due to inactive-timeout immediately after promotion? > > > > > > For synced slots, last_inactive_time and inactive_timeout are both > > > set. > > 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. > > > Let's say I bring down primary for promotion of standby and then > > > promote standby, there are chances that it may end up invalidating > > > synced slots (considering standby is not brought down during promotion > > > and thus inactive_timeout may already be past 'last_inactive_time'). > > > > > > > This raises the question of whether we need to set > > 'last_inactive_time' synced slots on the standby? > > Yeah, I think that last_inactive_time should stay at 0 on synced slots on the > standby because such slots are not usable anyway (until the standby gets > promoted). > > So, I think that last_inactive_time does not make sense if the slot never had > the chance to be active.
Right. Done that way i.e. not setting the last_inactive_time for slots both while releasing the slot and restoring from the disk. Also, I've added a TAP function to check if the captured times are sane per Bertrand's review comment. Please see the attached v20 patch. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
v20-0001-Track-last_inactive_time-in-pg_replication_slots.patch
Description: Binary data
