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

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 11:51:38
Message-ID: 20190329115138.GD1954@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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?
--
Michael

Attachment Content-Type Size
autovac-antiwrap-skip.patch text/x-diff 1.9 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2019-03-29 12:18:26 pgsql: Warn more strongly about the dangers of exclusive backup mode.
Previous Message Peter Eisentraut 2019-03-29 10:19:52 pgsql: Fix incorrect code in new REINDEX CONCURRENTLY code

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2019-03-29 11:51:58 Re: Inconsistencies in the behavior of CHR() function in PG.
Previous Message Peter Eisentraut 2019-03-29 11:48:09 fsync error handling in pg_receivewal, pg_recvlogical