Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, sawada(dot)mshk(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, sk(at)zsrv(dot)org, nasbyj(at)amazon(dot)com, andres(at)anarazel(dot)de, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru
Date: 2019-03-29 14:22:55
Message-ID: 20190329142255.GA22447@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 2019-Mar-29, Michael Paquier wrote:

> On Fri, Mar 29, 2019 at 09:11:47AM -0400, Andrew Dunstan wrote:
> > +                (errmsg_internal("found vacuum to prevent wraparound of
> > table \"%s.%s.%s\" to be not aggressive, so skipping",
> >
> > This might convey something to hackers, but I doubt it will convey much
> > to regular users. Perhaps something like "skipping redundant
> > anti-wraparound vacuum of table ..." would be better.
>
> "skipping redundant" is much better.

Yeah, that looks good to me too. I wonder if we really need it as LOG
though; we don't say anything for actions unless they take more than the
min duration, so why say something for a no-op that takes almost no time?
Maybe make it DEBUG1.

> > The comment is also a bit too tentative. Perhaps something like this
> > would do:
> >
> > Normally the relfrozenxid for an anti-wraparound vacuum will be old
> > enough to force an aggressive vacuum. However, a concurrent vacuum
> > might have already done this work that the relfroxzenxid in relcache
> > has been updated. If that happens this vacuum is redundant, so skip it.
>
> That works for me.

s/relfroxzenxid/relfrozenxid/

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2019-03-29 15:29:06 Re: pgsql: Compute XID horizon for page level index vacuum on primary.
Previous Message Michael Paquier 2019-03-29 14:03:49 Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-03-29 14:24:42 Re: pg_ctl on windows can't open postmaster.pid: Permission denied
Previous Message Laurenz Albe 2019-03-29 14:15:50 Re: table_privileges view always show object owner as a grantor