Re: postgresql 18 and shm

[Greg Troxel <gdt%lexort.com@localhost>]

Marc Baudoin <babafou%babafou.eu.org@localhost> writes:

> Greg Troxel <gdt%lexort.com@localhost> écrit :
>> 
>> What is kern.posix.semmax?  For me, it's 128, netbsd
>> 9/10/11. i386/earmv7hf-el/amd64/aarch64.
>
> 128 also (NetBSD default value).

I went to read the upstream docs, and they are quite comprehensive.

https://www.postgresql.org/docs/18/kernel-resources.html#SYSVIPC

It says that POSIX semaphores are not used on NetBSD; pgsql uses sysv,
as makes sense from the commentary so far.

>>   Is this a change  in resource usage by pgsql18 for the same configured
>>   connection limit, is it a change in the default connection limit, or
>>   is it something else?
>
> I would say something else.  Maybe related to the new
> asynchronous I/O system in PostgreSQL 18.

It seems they changed the scheme by which they group semaphores into
sets.

Having found that, I now think:

  1) Upstream documents this pretty well, but the error message doesn't
     really point to it.

     It could make sense for the rc.d script, if limits are low to print
     a "see $URL".  upstream is already addressing this, so we shouldn't
     also.

  2) Bumping up still seems good.  Am reading code.

  3) upstream pgsql uses POSIX on Linux and FreeBSD and sysv on the
     rest.  I wonder if one changes the build to use POSIX on NetBSD,
     how that works, and if it avoids this issue.

Reading pgsql 17 docs, I think 3 sets and 60 semaphores is enough, and
NetBSD default is 10 and 60.

It would be great if you can read the docs closely and understand all
the components that make up semaphore use, to see if things are as we'd
expect.  I don't understand why you need semmni so high, from reading.


I just proposed on tech-kern@ to move to 32/256.  The current limits are
from 4.4BSD in 1993.