Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` settingshould be documented
Date
Msg-id 20191105201145.GB32473@momjian.us
Whole thread Raw
In response to Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` setting should be documented  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, Oct 24, 2019 at 02:37:03PM -0400, Tom Lane wrote:
> I think this is confusingly bad English, and it's poor exposition
> because a minor detail (it must be pretty minor, if we got away
> without mentioning it at all for years) is injected into the middle
> of the basic statement of the variable's purpose.  I think what we'd
> be better off doing is to write a separate sentence mentioning the
> units, in more or less the same way that we generally handle the
> default value.  In <14850.1571941169@sss.pgh.pa.us> I suggested
> this revision for statement_timeout:
> 
>         Abort any statement that takes more than the specified duration.
>         If <varname>log_min_error_statement</varname> is set
>         to <literal>ERROR</literal> or lower, the statement that timed out
>         will also be logged.
>         If the value is specified as a plain number, it is measured in
>         milliseconds by default.
>         A value of zero (the default) disables the timeout.
> 
> (I'm not quite sure whether the ending "by default" is worth writing
> or not.)
> 
> Barring objections, I'll run around and make them all look like that.

Thanks for applying the improvement in your patch cfb7559083.  I was
torn between it being a minor issue and not wanting to devote a new
sentence about it, which is why I awkwardly used parentheses.

-- 
  Bruce Momjian  <bruce@momjian.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 +



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16095: Segfault while executing trigger
Next
From: Andrey Lepikhov
Date:
Subject: The XLogFindNextRecord() routine find incorrect record start pointafter a long continuation record