Thread: BUG #15396: initdb emits wrong comment for range foreffective_io_concurrency

The following bug has been logged on the website:

Bug reference:      15396
Logged by:          James Robinson
Email address:      james@jlr-photo.com
PostgreSQL version: 11beta3
Operating system:   OSX
Description:

inidb in 11 beta4 emits a postgresql.conf with the following:

  ...
  # - Asynchronous Behavior -

  #effective_io_concurrency = 0        # 1-1000; 0 disables prefetching
  ...

But un-commenting and changing to any value other than zero produces:

  2018-09-23 15:57:15.960 GMT [33648] LOG:  1 is outside the valid range for
parameter "effective_io_concurrency" (0 .. 0)

Something up here? If not a tunable knob, why describe it and / or have the
misleading comment?

beta4 Installed via macports.

Hello

effective_io_concurrency can not be set is your system does not support USE_POSIX_FADVISE. In this case only allowed
valuefor effective_io_concurrency is zero.
 
As far i know mac os does not support posix_fadvise.

Also this is documented behavior https://www.postgresql.org/docs/11/static/runtime-config-resource.html
> Asynchronous I/O depends on an effective posix_fadvise function, which some operating systems lack. If the function
isnot present then setting this parameter to anything but zero will result in an error. 
 

regards, Sergei

James Robinson <james@jlr-photo.com> writes:
>> On Sep 23, 2018, at 2:27 PM, Sergei Kornilov <sk@zsrv.org> wrote:
>> effective_io_concurrency can not be set is your system does not support USE_POSIX_FADVISE. In this case only allowed
valuefor effective_io_concurrency is zero. 
>> As far i know mac os does not support posix_fadvise.

>     Possibilities of augmenting either the initdb template comments according to if USE_POSIX_FADVISE or not, or
perhapsthe runtime error (probably harder). 

I don't think trying to cram something about this into
postgresql.conf.sample is advisable.  Those end-of-line comments need to
be *short*.  Plus, you'd almost certainly confuse people as to whether the
info was applicable to them or not.  Perhaps a better idea is to rejigger
things so that the bad news is delivered by check_effective_io_concurrency
rather than changing the hard limits of the GUC.  Then it'd be possible
to include an errdetail that only zero is supported on platforms that
lack posix_fadvise.

            regards, tom lane