Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition
Date: 2022-08-06 22:51:55
Message-ID: 20220806225155.GV19644@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 06, 2022 at 03:41:57PM -0700, Peter Geoghegan wrote:
> > > Note that a VACUUM that is an "automatic vacuum for inserted tuples" cannot
> > > [...] also be a "regular" autovacuum/VACUUM
> >
> > Why not ?

I think maybe you missed my intent in trimming the "anti-wraparound" part of
your text.

My point was concerning your statement that "autovacuum for inserted tuples ..
cannot also be a regular autovacuum" (meaning triggered by dead tuples).

> Well, autovacuum.c should have (and/or kind of already has) 3
> different triggering conditions. These are mutually exclusive
> conditions -- technically autovacuum.c always launches an autovacuum
> against a table because exactly 1 of the 3 thresholds were crossed.

The issue being that both thresholds can be crossed:

>> 2022-08-06 16:47:47.674 CDT autovacuum worker[12707] DEBUG: t: VAC: 99999 (THRESHOLD 50), INS: 99999 (THRESHOLD 1000), anl: 199998 (threshold 50)

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-08-06 23:08:27 Re: Cleaning up historical portability baggage
Previous Message Tom Lane 2022-08-06 22:42:03 Re: Cleaning up historical portability baggage