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

From Andres Freund
Subject Re: Testing autovacuum wraparound (including failsafe)
Date
Msg-id 20210424025303.wtehilaqjwhk2gb3@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)
List pgsql-hackers
Hi,

On 2021-04-23 19:42:30 -0700, Peter Geoghegan wrote:
> On Fri, Apr 23, 2021 at 7:33 PM Andres Freund <andres@anarazel.de> wrote:
> > Check it every so often, independent of whether there are indexes or
> > dead tuples? Or just check it at the boundaries.
>
> I think that the former suggestion might be better -- I actually
> thought about doing it that way myself.

Cool.


> The latter suggestion sounds like you're suggesting that we just check
> it at the beginning and the end in all cases (we do the beginning in
> all cases already, but now we'd also do the end outside of the loop in
> all cases). Is that right?

Yes.


> If that is what you meant, then you should note that there'd hardly be
> any check in the one-pass case with that scheme (apart from the
> initial check that we do already). The only work we'd be skipping at
> the end (in the event of that check triggering the failsafe) would be
> heap truncation, which (as you've pointed out yourself) doesn't seem
> particularly likely to matter.

I mainly suggested it because to me the current seems hard to
understand. I do think it'd be better to check more often. But checking
depending on the amount of dead tuples at the right time doesn't strike
me as a good idea - a lot of anti-wraparound vacuums will mainly be
freezing tuples, rather than removing a lot of dead rows. Which makes it
hard to understand when the failsafe kicks in.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Testing autovacuum wraparound (including failsafe)
Next
From: Amit Kapila
Date:
Subject: Re: [bug?] Missed parallel safety checks, and wrong parallel safety