bgwriter_lru_multiplier maximum value

On Mon, Apr 01, 2019 at 10:27:13AM +0000, PG Doc comments form wrote:

The server has an undocumented maximum value of 10 for
bgwriter_lru_multiplier, and will fail to start if it's set higher than
this:

LOG: 20 is outside the valid range for parameter "bgwriter_lru_multiplier"
(0 .. 10)
FATAL: configuration file "/.../pgdata/postgresql.conf" contains errors

I would suggest something like that:
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2050,7 +2050,8 @@ include_dir 'conf.d'
          Larger values provide some cushion against spikes in demand,
          while smaller values intentionally leave writes to be done by
          server processes.
-         The default is 2.0.
+         The default is 2.0.  The value can range from <literal>2.0</literal>
+         to <literal>10.0</literal>
          This parameter can only be set in the <filename>postgresql.conf</filename>
          file or on the server command line.
         </para>

Any opinions from others?
--
Michael

Michael Paquier <michael@paquier.xyz> writes:

On Mon, Apr 01, 2019 at 10:27:13AM +0000, PG Doc comments form wrote:

The server has an undocumented maximum value of 10 for
bgwriter_lru_multiplier, and will fail to start if it's set higher than
this:

Any opinions from others?

I don't think it's generally our practice to specify min and max
values in config.sgml. If we were to start doing so, we'd need
a much bigger patch than this, and it'd be an ongoing maintenance
issue.

Unless there's some reason I'm missing why the limits are more
significant for this variable than for others?

regards, tom lane

Hi all,

We do document the range for some parameters:

- bgwriter_flush_after: "The valid range is between 0, which disables
forced writeback, and 2MB."
- effective_io_concurrency (integer): "The allowed range is 1 to 1000,
or zero to disable issuance of asynchronous I/O requests."
- backend_flush_after (integer): "The valid range is between 0, which
disables forced writeback, and 2MB."

My argument for documenting this one would extend to all parameters that
can only be set at server startup time, and for which exceeding the maximum
(or minimum) value would cause the server to fail to start. In these cases
the change cannot be tested without risk of downtime. It's also not clear
where to look (e..g in the code) for the limits on allowed range.

+ The default is 2.0. The value can range from

<literal>2.0</literal>

If we are going to change it, the minimum value is apparently 0, not 2.

Thanks, Chris.

On Mon, 1 Apr 2019 at 14:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:

On Mon, Apr 01, 2019 at 03:09:39PM +0100, Chris Wilson wrote:

If we are going to change it, the minimum value is apparently 0, not
2.

Ditto. I misread guc.c.
--
Michael