Date: Mon, 24 Sep 2018 11:29:34 -0700
From: Andres Freund <andres@anarazel.de>
To: "Nasby, Jim" <nasbyj@amazon.com>
Cc: Sergei Kornilov <sk@zsrv.org>, Robert Haas <robertmhaas@gmail.com>,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	Michael Paquier <michael@paquier.xyz>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Improve autovacuum logging for aggressive and
 anti-wraparound ru
Message-ID: <20180924182934.rpl3lkoisy5o2tx4@alap3.anarazel.de>
References: <E1g0aGi-0000uN-Sq@gemulon.postgresql.org>
 <20180914153554.562muwr3uwujno75@alvherre.pgsql>
 <CA+Tgmoa7JJG0g2rCR=m8wXzExZDBpHPo04a5FyV-EotknVDONg@mail.gmail.com>
 <7924791537551496@myt5-c56023d17c6b.qloud-c.yandex.net>
 <20180921174347.wvszsn7uk56zvz7o@alap3.anarazel.de>
 <0A11E30F-DDDE-422F-B22A-3F6E3AA7A0A2@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0A11E30F-DDDE-422F-B22A-3F6E3AA7A0A2@amazon.com>
Precedence: bulk

On 2018-09-24 18:25:46 +0000, Nasby, Jim wrote:
> 
> > On Sep 21, 2018, at 12:43 PM, Andres Freund <andres@anarazel.de> wrote:
> > 
> >> But as far i can see it is possible have aggressive non-wraparound vacuum. One important difference - regular and aggressive regular can be canceled by backend,.wraparound autovacuum can not. (by checking PROC_VACUUM_FOR_WRAPAROUND in src/backend/storage/lmgr/proc.c )
> > 
> > Yes, without checking the code, they should be different. Aggressive is
> > controlled by vacuum_freeze_table_age whereas anti-wrap is controlled by
> > autovacuum_freeze_max_age (but also implies aggressive).
> 
> Right, except that by the time you get into the vacuum code itself nothing should really care about that difference. AFAICT, the only thing is_wraparound is being used for is to set MyPgXact->vacuumFlags |= PROC_VACUUM_FOR_WRAPAROUND, which prevents the deadlock detector from killing an autovac process that’s trying to prevent a wraparound. I think it’d be clearer to remove is_wraparound and move the check from vacuum_rel() into lazy_vacuum_rel() (which is where the limits for HeapTupleSatisfiesVacuum get determined). Something like the attached.

I'm very doubtful this is an improvement. Especially with the upcoming
pluggable storage work making vacuumlazy.c heap specific, while vacuum.c
stays generic.  The concept of something like
PROC_VACUUM_FOR_WRAPAROUND, should imo not be pushed down that much
(even if criteria for it might).

Greetings,

Andres Freund