Hello,
Currently the message shows the '%d skipped-frozen' message but
it is insufficient to verify the true effect. This is a patch to
show mode as 'aggressive' or 'normal' in the closing message of
vacuum. %d frozen-skipped when 'aggressive mode' shows the true
effect of ALL_FROZEN.
I will add this patch to CF2017-09.
At Tue, 4 Apr 2017 20:29:38 +0900, Masahiko Sawada <sawada.m...@gmail.com>
wrote in <CAD21AoBiw96efy+tynvMLFQWERfPnhO53B=xfw9yyzejn-f...@mail.gmail.com>
> On Tue, Apr 4, 2017 at 10:09 AM, Kyotaro HORIGUCHI
> <horiguchi.kyot...@lab.ntt.co.jp> wrote:
> > | =# vacuum freeze verbose it;
> > | INFO: vacuuming "public.it" in aggressive mode
> > | INFO: "it": found 0 removable, 0 nonremovable row versions in 0 out of 0
> > pages
> > ...
> > | Skipped 0 pages due to buffer pins, 0 frozen pages.
> >
> > I still feel a bit uneasy about the word "aggressive" here.
>
> I think we can use the word "aggressive" here since we already use the
> word "aggressive vacuum" in docs[1], but it might be easily
> misunderstood.
>
> [1] https://www.postgresql.org/docs/9.6/static/routine-vacuuming.html
>
> >Is it better to be "freezing" or something?
>
> An another idea can be something like "prevent wraparound". The
> autovaucum process doing aggressive vacuum appears in pg_stat_activity
> with the word ".... (to prevent wraparound)". This word might be more
> user friendly IMO.
Hmm. This appears to be in several form.
https://www.postgresql.org/docs/devel/static/sql-vacuum.html
> aggressive “freezing” of tuples. ... Aggressive freezing
https://www.postgresql.org/docs/devel/static/routine-vacuuming.html
> VACUUM will perform an aggressive vacuum,
> an anti-wraparound autovacuum
https://www.postgresql.org/docs/devel/static/runtime-config-client.html
> ACUUM performs an aggressive scan
ps title
>.... (to prevent wraparound)
The nearest common wording seems to be just aggressive (vacuum)
so I left it alone in the attached patch.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
>From 009507d5ddb33229e4c866fef206962de39317cc Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horiguchi.kyot...@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 "n 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" or "normal" in
autovacuum logs and VACUUM VERBOSE message
---
src/backend/commands/vacuumlazy.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/backend/commands/vacuumlazy.c b/src/backend/commands/vacuumlazy.c
index 45b1859..71ecd50 100644
--- a/src/backend/commands/vacuumlazy.c
+++ b/src/backend/commands/vacuumlazy.c
@@ -373,10 +373,11 @@ lazy_vacuum_rel(Relation onerel, int options, VacuumParams *params,
* emitting individual parts of the message when not applicable.
*/
initStringInfo(&buf);
- appendStringInfo(&buf, _("automatic vacuum of table \"%s.%s.%s\": index scans: %d\n"),
+ appendStringInfo(&buf, _("automatic vacuum of table \"%s.%s.%s\": mode: %s, index scans: %d\n"),
get_database_name(MyDatabaseId),
get_namespace_name(RelationGetNamespace(onerel)),
RelationGetRelationName(onerel),
+ aggressive ? "aggressive" : "normal",
vacrelstats->num_index_scans);
appendStringInfo(&buf, _("pages: %u removed, %u remain, %u skipped due to pins, %u skipped frozen\n"),
vacrelstats->pages_removed,
@@ -487,9 +488,9 @@ lazy_scan_heap(Relation onerel, int options, LVRelStats *vacrelstats,
relname = RelationGetRelationName(onerel);
ereport(elevel,
- (errmsg("vacuuming \"%s.%s\"",
+ (errmsg("vacuuming \"%s.%s\" in %s mode",
get_namespace_name(RelationGetNamespace(onerel)),
- relname)));
+ relname, aggressive ? "aggressive" : "normal")));
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
