Re: pgsql: Improve autovacuum logging for aggressive andanti-wraparound ru - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: pgsql: Improve autovacuum logging for aggressive andanti-wraparound ru
Date
Msg-id e454b280-d7b5-1798-b01c-213b663d8907@2ndQuadrant.com
Whole thread Raw
In response to Re: pgsql: Improve autovacuum logging for aggressive andanti-wraparound ru  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pgsql: Improve autovacuum logging for aggressive andanti-wraparound ru
List 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




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: fsync error handling in pg_receivewal, pg_recvlogical
Next
From: Alexander Korotkov
Date:
Subject: Re: jsonpath