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
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 |