Re: BUG #18094: max max_connections cannot be set

On Friday, September 8, 2023, Nikolay Samokhvalov <nikolay(at)samokhvalov(dot)com>
wrote:

>
>
> On Fri, Sep 8, 2023 at 06:57 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
>> > On Thu, Sep 7, 2023 at 9:25 PM Nikolay Samokhvalov <
>> nikolay(at)samokhvalov(dot)com>
>> > wrote:
>> >> nik=# select max_val from pg_settings where name = 'max_connections';
>> >> max_val
>> >> ---------
>> >> 262143
>> >> (1 row)
>> >>
>> >> -- here is why
>>
>> > Glossed right over that...yeah, quite a few settings seem to have a
>> max_val
>> > of "unsigned numeric", I'd be curious whether they all have some
>> > non-datatype maximum recognized during runtime that pg_settings is
>> unable
>> > to see.
>>
>> Yeah, there are for example plenty of entries with max_val of INT_MAX,
>> but that doesn't necessarily mean you can set them that high. The
>> max_val is *a* constraint, it's not the *only* constraint
>
>
> Thank you for the explanation.
>
> Then, I think, the column name may be misleading to many. I will now
> memorize that it's not the actual max value, but I'm sure in a couple of
> years I'll forget (as it happens to me often), and think again that this is
> a bug.
>

Maybe a documentation improvement… but bug or not it doesn’t seem worth the
effort to try too hard here. I already noted that limits based upon data
type size are probably insane to actually approach in reality and getting
an error message at some marginally lower value as in this case might be a
bit surprising but it isn’t at all harmful.

David J.