From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
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 13:11:47 |
Message-ID: | e454b280-d7b5-1798-b01c-213b663d8907@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On 3/29/19 7:51 AM, Michael Paquier wrote:
> On Sat, Mar 09, 2019 at 10:15:37AM +0900, Michael Paquier wrote:
>> I am adding an open item about that. I think I could commit the
>> patch, but I need to study it a bit more first.
> So, coming back to this thread, and studying the problem again, it
> looks that the diagnostic that a non-aggressive, anti-wraparound
> vacuum could be triggered because the worker sees trouble in the
> force because of some activity happening in parallel. Hence, if we
> face this case, it looks right to skip the vacuum for this relation.
>
> Attached is an updated patch with a better error message, more
> comments, and the removal of the anti-wraparound non-aggressive log
> which was added in 28a8fa9. The error message could be better I
> guess. Suggestions are welcome.
>
> Thoughts?
+ (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.
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.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-03-29 14:01:08 | pgsql: Reorganize Notes section in documentation of pg_checksums |
Previous Message | Peter Eisentraut | 2019-03-29 12:37:22 | pgsql: doc: Refine README.links further |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2019-03-29 13:15:40 | Re: jsonpath |
Previous Message | Michael Paquier | 2019-03-29 13:05:05 | Re: fsync error handling in pg_receivewal, pg_recvlogical |