Re: BUG #18094: max max_connections cannot be set

From: Nikolay Samokhvalov <nikolay(at)samokhvalov(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18094: max max_connections cannot be set
Date: 2023-09-08 14:04:21
Message-ID: CANNMO+LBQB9Yy+-A0ObiG3qDORKN78asyRER82RtciT0-=b72A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-09-08 14:33:11 Re: BUG #18096: In edge-triggered epoll and kqueue, PQconsumeInput/PQisBusy are insufficient for correct async ops.
Previous Message Tom Lane 2023-09-08 13:57:05 Re: BUG #18094: max max_connections cannot be set