Re: Intermittent buildfarm failures on wrasse - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Intermittent buildfarm failures on wrasse
Date
Msg-id 20220417143615.qutrww3vffe6gcjb@alap3.anarazel.de
Whole thread Raw
In response to Re: Intermittent buildfarm failures on wrasse  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Intermittent buildfarm failures on wrasse
List pgsql-hackers
Hi,

On 2022-04-15 11:12:34 -0700, Peter Geoghegan wrote:
> On Fri, Apr 15, 2022 at 10:43 AM Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Stabilizing the test_decoding checks, take N
Next
From: Andrew Dunstan
Date:
Subject: Re: pgsql: Add TAP test for archive_cleanup_command and recovery_end_comman