Hi Hayato, Thank you for taking a look.
> > 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? Are you concerned if we did the check on a per table case? Or in the current situation where it's only once per-worker. > > > > 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. > I feel that the timeout is used as a way to roughly address storage accumulation or VACUUM not progressing due to slots. > In contrast, is there a possibility that XID-age check can be done only at > VACUUM? It's also done in CHECKPOINT because there can be stale replication slots on standby that aren't there on writer. We would still want them to be invalidated. > Regarding the patch, try_replication_slot_invalidation() and > ReplicationSlotIsXIDAged() > do the same task. Can we reduce duplicated part? Thanks for catching, I thought I did this but guess not. Updated in the latest attachment. -- John Hsu - Amazon Web Services
0045-Add-XID-age-based-replication-slot-invalidation.patch
Description: Binary data
