Re: Testing autovacuum wraparound (including failsafe) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Testing autovacuum wraparound (including failsafe)
Date
Msg-id 20210424023314.iem2gxm7cuaj66au@alap3.anarazel.de
Whole thread Raw
In response to Re: Testing autovacuum wraparound (including failsafe)  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Testing autovacuum wraparound (including failsafe)  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Hi,

On 2021-04-23 19:15:43 -0700, Peter Geoghegan wrote:
> > The failsafe mode affects the table scan itself by disabling cost
> > limiting. As far as I can see the ways it triggers for the table scan (vs
> > truncation or index processing) are:
> >
> > 1) Before vacuuming starts, for heap phases and indexes, if already
> >    necessary at that point
> > 2) For a table with indexes, before/after each index vacuum, if now
> >    necessary
> > 3) On a table without indexes, every 8GB, iff there are dead tuples, if now necessary
> >
> > Why would we want to trigger the failsafe mode during a scan of a table
> > with dead tuples and no indexes, but not on a table without dead tuples
> > or with indexes but fewer than m_w_m dead tuples? That makes little
> > sense to me.
> 
> What alternative does make sense to you?

Check it every so often, independent of whether there are indexes or
dead tuples? Or just check it at the boundaries.

I'd make it dependent on the number of pages scanned, rather than the
block distance to the last check - otherwise we might end up doing it
way too often when there's only a few individual pages not in the freeze
map.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Testing autovacuum wraparound (including failsafe)
Next
From: Peter Geoghegan
Date:
Subject: Re: Testing autovacuum wraparound (including failsafe)