Andres Freund <and...@anarazel.de> writes:
> On 2024-12-18 12:00:48 -0500, Tom Lane wrote:
>> 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
Hmm, on mamba's host I see
proc.curproc.rlimit.descriptors.soft = 128
proc.curproc.rlimit.descriptors.hard = 1772
I had actually tried building with unnamed semas there a couple days
ago, and found that the postmaster failed to start. 21fb39cb0 should
have alleviated that (didn't test it yet). But we're still in a
very limited-resource regime. That with the old performance tests
you dredged up makes me not want to switch sema types.
>> 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.
Fair, seems like we're on the same page.
regards, tom lane
