Re: postgresql 18 and shm

[Marc Baudoin <babafou%babafou.eu.org@localhost>]

Greg Troxel <gdt%lexort.com@localhost> écrit :
> Marc Baudoin <babafou%babafou.eu.org@localhost> writes:
> 
> >> [pgsql 18 wants lots of semaphore resources]
> 
> > Have a look at this thread from last year:
> >
> > https://mail-index.netbsd.org/pkgsrc-users/2025/10/25/msg042112.html
> >
> > The setting that works for me is:
> >
> > kern.ipc.semmni=20
> > kern.ipc.semmns=200
> 
> What is kern.posix.semmax?  For me, it's 128, netbsd
> 9/10/11. i386/earmv7hf-el/amd64/aarch64.

128 also (NetBSD default value).

> It sounds like we should do some combination of:
> 
>   0) file a bug upstream that the error is not as specific as it could
>   be, and does not point to the specific call that failed
> 
>   1) increase the defaults in NetBSD (and pull up to 11, 10, and, until
>      11 is released, 9 :-) to be high enough.

Which is not that much higher than the present default values.

>   2) In /etc/rc.d/pgsql, check the semaphore limits and for each that is
>      not enough *for the default pgsql config*
>      a) print a warning
>      b) print a warning and fail

And suggest better values.

>      c) increase the limit

Not sure that would be the best way.

> The big questions in my mind are:
> 
>   What are the resource usage considerations of increased semaphore
>   limits?  I would guess they are pretty low, dating from a VAX with 1MB
>   of RAM, and just haven't gotten increased, and that the proposed
>   larger values would not hurt, except on people trying to serious
>   retrocomputing on 32MB machines.

I concur.

>   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.