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

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

In response to

Responses

Browse pgsql-committers by date

  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

Browse pgsql-hackers by date

  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