Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1iNhz2-0008Et-Pc
	for pgsql-docs@arkaria.postgresql.org; Thu, 24 Oct 2019 18:37:16 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1iNhz1-0002pG-0N
	for pgsql-docs@arkaria.postgresql.org; Thu, 24 Oct 2019 18:37:15 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1iNhz0-0002p5-PI; Thu, 24 Oct 2019 18:37:14 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1iNhyt-0003zG-PA; Thu, 24 Oct 2019 18:37:14 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x9OIb3qk015883;
	Thu, 24 Oct 2019 14:37:03 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Daniel Gustafsson <daniel@yesql.se>, basil.bourque@gmail.com,
        pgsql-bugs@lists.postgresql.org, pgsql-docs@lists.postgresql.org
Subject: Re: BUG #15912: The units of `autovacuum_vacuum_cost_delay` setting
 should be documented
In-reply-to: <20191009014955.GA3191@momjian.us>
References: <C6E10B26-97E0-4B4D-9AEE-E26A7E2263F9@yesql.se>
 <20190726220242.GA16906@alvherre.pgsql>
 <20190727214130.bjgyv2holjng3oeb@momjian.us>
 <20191009014955.GA3191@momjian.us>
Comments: In-reply-to Bruce Momjian <bruce@momjian.us>
	message dated "Tue, 08 Oct 2019 21:49:55 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15881.1571942223.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 24 Oct 2019 14:37:03 -0400
Message-ID: <15882.1571942223@sss.pgh.pa.us>
List-Id: <pgsql-docs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-docs@lists.postgresql.org>
List-Owner: <mailto:pgsql-docs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-docs>
Precedence: bulk

[ cc'ing pgsql-docs as well ]

Bruce Momjian <bruce@momjian.us> writes:
> I applied a modified version of this patch.  I didn't backpatch it past
> PG 12 because earlier releases were just too different.

I happened to stumble across the effects of this patch while trying
to improve our explanation of statement_timeout.  I follow the goal
of explaining what the default units are, but I really dislike the
way you did it:

+        Abort any statement that takes more than the specified duration
+        (defaults to milliseconds), starting from the time the command ar=
rives at the server
         from the client. ...

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.

			regards, tom lane