Re: Regression tests fail on OpenBSD due to low semmns value

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