Re: Intermittent buildfarm failures on wrasse

Hi,

On 2022-04-15 11:12:34 -0700, Peter Geoghegan wrote:
> On Fri, Apr 15, 2022 at 10:43 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I think it'd be interesting - particularly for large relations or when
> > looking to adjust autovac cost limits.
>
> > Something like:
> > removable cutoff: %u, age at start: %u, age at end: %u...
>
> Part of the problem here is that we determine VACUUM's FreezeLimit by
> calculating `OldestXmin - vacuum_freeze_min_age` (more or less [1]).

What the message outputs is OldestXmin and not FreezeLimit though. And
FreezeLimit doesn't affect "dead but not yet removable".

IOW, the following might be right, but that seems independent of
improving the output of
diff = (int32) (ReadNextTransactionId() - OldestXmin);
appendStringInfo(&buf,
_("removable cutoff: %u, which was %d XIDs old when operation ended\n"),
OldestXmin, diff);

> Why should we do less freezing due to the presence of an old snapshot?
> Sure, that has to happen with those XIDs that are fundamentally
> ineligible for freezing due to the presence of the old snapshot -- but
> what about those XIDs that *are* eligible, and still don't get frozen
> at first?
>
> We should determine FreezeLimit by calculating `NextXID -
> vacuum_freeze_min_age ` instead (and then clamp, to make sure that
> it's always <= OldestXmin). That approach would make our final
> FreezeLimit "strictly age-based".
>
> [1] We do something a bit like this when OldestXmin is already very
> old -- then FreezeLimit is the same value as OldestXmin (see WARNING
> from vacuum_set_xid_limits() function). That's better than nothing,
> but doesn't change the fact that our general approach to calculating
> FreezeLimit makes little sense.

Greetings,

Andres Freund