On Tue, Apr 2, 2024 at 11:58 AM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > > > Or a simple solution is that the slotsync worker updates > > inactive_since as it does for non-synced slots, and disables > > timeout-based slot invalidation for synced slots. > > Yeah, I think the main question to help us decide is: do we want to invalidate > "inactive" synced slots locally (in addition to synchronizing the invalidation > from the primary)?
I think this approach looks way simpler than the other one. The other approach of linking inactive_since on the standby for synced slots to the actual LSNs (or other slot parameters) being updated or not looks more complicated, and might not go well with the end user. However, we need to be able to say why we don't invalidate synced slots due to inactive timeout unlike the wal_removed invalidation that can happen right now on the standby for synced slots. This leads us to define actually what a slot being active means. Is syncing the data from the remote slot considered as the slot being active? On the other hand, it may not sound great if we don't invalidate synced slots due to inactive timeout even though they hold resources such as WAL and XIDs. -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
