From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | 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, alvherre(at)2ndquadrant(dot)com, 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:03:49 |
Message-ID: | 20190329140349.GI1954@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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.
> 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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-03-29 14:22:55 | Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru |
Previous Message | Michael Paquier | 2019-03-29 14:01:08 | pgsql: Reorganize Notes section in documentation of pg_checksums |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-03-29 14:10:14 | Re: Enable data checksums by default |
Previous Message | Michael Paquier | 2019-03-29 14:01:14 | Re: Offline enabling/disabling of data checksums |