Hi, On 2024-12-18 12:00:48 -0500, Tom Lane wrote: > Andres Freund <and...@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
