Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor

On Tue, Jun 26, 2018 at 7:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> > 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)
>
> %g, unmodified, is a bad idea because it loses a lot of precision
> in some cases (due to the assumption that nobody cares about more
> than six digits). Maybe you could fix that by using %.15g or some
> such, but...
>
> I think that the original patch to use DBL_MAX was itself a bad idea
> and should be rethought. It creates (what is in principle) a
> platform-dependent limit, for no adequate justification. Why not
> just set it to 1e9 or 1e10 or some such?

Yes, I see that it was a bad idea, because many of buildfarm member
are turning red...

I choose DBL_MAX for the sake of uniformity, because we're currently
using DBL_MAX for floating point GUCs and reloptions, which allows
large values. But we didn't test them for overflow yet...

So, let's switch to 1e10 limit? Patch is attached.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company