Hi,
On 2024-12-18 12:00:48 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Maybe we should consider switching those platforms to unnamed posix
> > semaphores?
>
> I already looked into that. OpenBSD still doesn't have cross-process
> posix semaphores, at least according to its man page.
Ugh, I had missed that:
This implementation does not support shared semaphores, and reports this fact
by setting errno to EPERM. This is perhaps a stretch of the intention of
POSIX, but is compliant, with the caveat that sem_init() always reports a
permissions error when an attempt to create a shared semaphore is made.
That's such a stupid argument that I kinda just want to rip out openbsd
support out of postgres :)
> NetBSD does, but they consume an FD per sema, which is actually worse
> because the default max-open-files-per-process is none too large either.
Doesn't seem that bad on netbsd 10. Via Bilal's netbsd CI patch, I get:
# sysctl proc.curproc.rlimit.descriptors
proc.curproc.rlimit.descriptors.soft = 1024
proc.curproc.rlimit.descriptors.hard = 3404
> > But TBH, nobody uses openbsd and netbsd if performance matters even one
> > iota. And considering a bunch of postgres changes to deal with idiotic default
> > sysv limits doesn't feal like a sensible thing to do in 2024.
>
> Yeah, I would not expend a lot of effort on this. But two one-line
> changes doesn't seem unreasonable.
Agreed for stuff like SEMAS_PER_SET. I just don't think it's a good idea to
invest in lowering our default semaphore requirements by lowering various
default process limits or such.
Greetings,
Andres Freund
