Re: [HACKERS] show "aggressive" or not in autovacuum logs - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: [HACKERS] show "aggressive" or not in autovacuum logs
Date
Msg-id 20171026.171856.28343712.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] show "aggressive" or not in autovacuum logs  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [HACKERS] show "aggressive" or not in autovacuum logs
List pgsql-hackers
Thank you for the comment.

(Thank you Sawada-san for reviewng, too.)

At Thu, 19 Oct 2017 13:03:38 +0200, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote in
<20171019110338.awwzc3y674co7wof@alvherre.pgsql>
> Kyotaro HORIGUCHI wrote:
> 
> > How about the followings?
> > 
> > "automatic [agressive ]vacuum of table \"%s..."
> > "[aggressive ]vacuuming \"%s..."
> 
> That form of log message seems acceptable to me (first one is missing a 'g').
> 
> In any case, please do not construct the sentence with %s expanding the
> word, because that is going to cause a problem for translations.  Use an
> 'if' test with two full sentences instead.  Yes, as Robert said, it's
> going to add more strings, but that's okay.

Thank you. I forgot that point. Changed them so that the messages
are detected as msgids.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
From 7252bfc0fafcf9d4d38067913325cf82c88d1e1e Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horiguchi.kyotaro@lab.ntt.co.jp>
Date: Mon, 28 Aug 2017 13:12:25 +0900
Subject: [PATCH] Show "aggressive" or not in vacuum messages

VACUUM VERBOSE or autovacuum emits log message with "%u skipped
frozen" but we cannot tell whether the vacuum was non-freezing (or not
aggressive) vacuum or freezing (or aggressive) vacuum having no tuple
to freeze. This patch adds indication of aggressive (auto)vacuum in
log messages and VACUUM VERBOSE message.
---src/backend/commands/vacuumlazy.c | 21 ++++++++++++++++-----1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
index 30b1c08..1080fcf 100644
--- a/src/backend/commands/vacuumlazy.c
+++ b/src/backend/commands/vacuumlazy.c
@@ -355,6 +355,7 @@ lazy_vacuum_rel(Relation onerel, int options, VacuumParams *params,
     params->log_min_duration))        {            StringInfoData buf;
 
+            char *msgfmt;            TimestampDifference(starttime, endtime, &secs, &usecs);
@@ -373,7 +374,11 @@ lazy_vacuum_rel(Relation onerel, int options, VacuumParams *params,             * emitting
individualparts of the message when not applicable.             */            initStringInfo(&buf);
 
-            appendStringInfo(&buf, _("automatic vacuum of table \"%s.%s.%s\": index scans: %d\n"),
+            if (aggressive)
+                msgfmt = _("automatic aggressive vacuum of table \"%s.%s.%s\": index scans: %d\n");
+            else
+                msgfmt = _("automatic vacuum of table \"%s.%s.%s\": index scans: %d\n");
+            appendStringInfo(&buf, msgfmt,                             get_database_name(MyDatabaseId),
            get_namespace_name(RelationGetNamespace(onerel)),
RelationGetRelationName(onerel),
@@ -486,10 +491,16 @@ lazy_scan_heap(Relation onerel, int options, LVRelStats *vacrelstats,    pg_rusage_init(&ru0);
relname= RelationGetRelationName(onerel);
 
-    ereport(elevel,
-            (errmsg("vacuuming \"%s.%s\"",
-                    get_namespace_name(RelationGetNamespace(onerel)),
-                    relname)));
+    if (aggressive)
+        ereport(elevel,
+                (errmsg("aggressive vacuuming \"%s.%s\"",
+                        get_namespace_name(RelationGetNamespace(onerel)),
+                        relname)));
+    else
+        ereport(elevel,
+                (errmsg("vacuuming \"%s.%s\"",
+                        get_namespace_name(RelationGetNamespace(onerel)),
+                        relname)));    empty_pages = vacuumed_pages = 0;    num_tuples = tups_vacuumed = nkeep =
nunused= 0;
 
-- 
2.9.2


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: 高增琦
Date:
Subject: [HACKERS] Try to fix endless loop in ecpg with informix mode
Next
From: Michael Meskes
Date:
Subject: Re: [HACKERS] [bug fix] ECPG: fails to recognize embedded parameters