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
