On Thu, Mar 18, 2021 at 3:41 PM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Wed, Mar 17, 2021 at 11:23 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > Attached the updated patch that can be applied on top of your v3 patches.
>
> Some feedback on this:
>
> * I think that we can afford to be very aggressive here, because we're
> checking dynamically. And we're concerned about extremes only. So an
> age of as high as 1 billion transactions seems like a better approach.
> What do you think?
If we have the constant threshold of 1 billion transactions, a vacuum
operation might not be an anti-wraparound vacuum and even not be an
aggressive vacuum, depending on autovacuum_freeze_max_age value. Given
the purpose of skipping index vacuuming in this case, I think it
doesn't make sense to have non-aggressive vacuum skip index vacuuming
since it might not be able to advance relfrozenxid. If we have a
constant threshold, 2 billion transactions, maximum value of
autovacuum_freeze_max_age, seems to work.
>
> * I think that you need to remember that we have decided not to do any
> more index vacuuming, rather than calling
> check_index_cleanup_xid_limit() each time -- maybe store that
> information in a state variable.
>
> This seems like a good idea because we should try to avoid changing
> back to index vacuuming having decided to skip it once.
Once decided to skip index vacuuming due to too old relfrozenxid
stuff, the decision never be changed within the same vacuum operation,
right? Because the relfrozenxid is advanced at the end of vacuum.
> Also, we need
> to refer to this in lazy_scan_heap(), so that we avoid index cleanup
> having also avoided index vacuuming. This is like the INDEX_CLEANUP =
> off case, which is also only for emergencies. It is not like the
> SKIP_VACUUM_PAGES_RATIO case, which is just an optimization.
Agreed with this point. I'll fix it in the next version patch.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
