On Tue, Jun 26, 2018 at 3:59 PM Alexander Korotkov <[email protected]> wrote: > > On Tue, Jun 26, 2018 at 3:35 PM Alexander Korotkov > <[email protected]> wrote: > > vacuum_cleanup_index_scale_factor is used barely to protect against > > stalled index statistics. And after detailed consideration it appears > > that risk of stalled index statistics is low. And it would be nice to > > allow advanced users setting higher values of > > vacuum_cleanup_index_scale_factor. So, set upper limit for these > > GUC and reloption to DBL_MAX. > > BTW, this line looks cumbersome. > > +DETAIL: Valid values are between "0.000000" and > "179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000". > > It's not something introduced by this patch, because other reloptions > behave the same. Should we change output format for real reloption > boundaries to '%g' (as guc.c does). It looks much better. > > ERROR: -1 is outside the valid range for parameter "random_page_cost" > (0 .. 1.79769e+308)
See attached patch changing output format for reloption real boundaries from "%f" to "%g". ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
change-reloption-real-boundaries-output-format.patch
Description: Binary data
