From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, basil(dot)bourque(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` setting should be documented |
Date: | 2019-10-09 01:49:55 |
Message-ID: | 20191009014955.GA3191@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-docs |
On Sat, Jul 27, 2019 at 05:41:30PM -0400, Bruce Momjian wrote:
> On Fri, Jul 26, 2019 at 06:02:42PM -0400, Alvaro Herrera wrote:
> > Now you could complain that this is inconsistent with other
> > descriptions; for example, log_autovacuum_min_duration talks about
> > milliseconds, which sounds a bit archaic to me:
> >
> > Causes each action executed by autovacuum to be logged if it ran for
> > at least the specified number of milliseconds. Setting this to zero
> > logs all autovacuum actions. -1 (the default) disables logging
> > autovacuum actions. For example, if you set this to 250ms then all
> > automatic vacuums and analyzes that run 250ms or longer will be
> > logged. In addition, when this parameter is set to any value other
> > than -1, a message will be logged if an autovacuum action is skipped
> > due to a conflicting lock or a concurrently dropped relation.
> > Enabling this parameter can be helpful in tracking autovacuum
> > activity. This parameter can only be set in the postgresql.conf file
> > or on the server command line; but the setting can be overridden for
> > individual tables by changing table storage parameters.
> >
> >
> > I'm not really sure what's a good way to attack this problem, but I
> > doubt that focusing on just one description is a sufficient solution.
>
> Yes, I looked at this earlier in the week and had the same conclusion.
> I went over config.sgml and saw many inconsistencies of the same type
> being complained about here.
>
> I went through the file and found a number of cases using milliseconds
> and kilobytes that were unclear, and adjusted them. I dealt only with
> the cases where the base unit (seconds/bytes) was not the default unit.
> Patch attached.
I applied a modified version of this patch. I didn't backpatch it past
PG 12 because earlier releases were just too different.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-10-09 04:42:07 | Re: BUG #16039: PANIC when activating replication slots in Postgres 12.0 64bit under Windows |
Previous Message | Martín Marqués | 2019-10-08 19:56:38 | Re: Non-null values of recovery functions after promote or crash of primary |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2019-10-09 05:48:50 | First WAL segment file that initdb creates |
Previous Message | Stephen Frost | 2019-10-08 16:39:26 | Re: I'm surprised to see the word master here |