Dear John,
> The first issue can be mitigated by 'max_slot_wal_keep_size'. However
> in the second case there are no good mechanisms to prioritize write
> availability of the database and avoid wraparound. The new GUC
> 'idle_replication_slot_timeout' partially addresses the concern if you
> have similar workloads. However it's hard to set the same setting
> across a fleet of different applications.
IIUC, the feature can directly avoid the wraparound issue than other
invalidation mechanism. The motivation seems enough for me.
> The patch currently attempts to invalidate once-per-autovacuum worker.
> We're wondering if it should attempt invalidation on a per-relation
> basis within the vacuum call itself. That would account for scenarios
> where the cost_delay or naptime is high between autovac executions.
I have a concern that age calculation acquire the lock for XidGenLock thus
performance can be affected. Do you have insights for it?
>
> Invalidation happens in CHECKPOINT, similar to
> 'idle_replication_slot_timeout', and when VACUUM occurs.
Let me confirm because I'm new. VACUUM can also trigger because old XID make
VACUUM fail, right? Timeout is aimed for WAL thus it is not so related with VACUUM,
which does not recycle segments.
In contrast, is there a possibility that XID-age check can be done only at VACUUM?
Regarding the patch, try_replication_slot_invalidation() and ReplicationSlotIsXIDAged()
do the same task. Can we reduce duplicated part?
Best regards,
Hayato Kuroda
FUJITSU LIMITED
