Обсуждение: bgwriter_lru_multiplier maximum value
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/runtime-config-resource.html Description: 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
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:
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
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