Re: BUG #18094: max max_connections cannot be set
От | David G. Johnston |
---|---|
Тема | Re: BUG #18094: max max_connections cannot be set |
Дата | |
Msg-id | CAKFQuwb7mO0qouMMnNt4QuOyJGiXgA=LJUrWz988Zvem79cpwA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #18094: max max_connections cannot be set (Nikolay Samokhvalov <nikolay@samokhvalov.com>) |
Список | pgsql-bugs |
On Friday, September 8, 2023, Nikolay Samokhvalov <nikolay@samokhvalov.com> wrote:
On Fri, Sep 8, 2023 at 06:57 Tom Lane <tgl@sss.pgh.pa.us> wrote:"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Thu, Sep 7, 2023 at 9:25 PM Nikolay Samokhvalov <nikolay@samokhvalov.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* constraintThank 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.
В списке pgsql-bugs по дате отправления: