Re: Regression tests fail on OpenBSD due to low semmns value
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter@eisentraut.org>,
Andrew Dunstan <andrew@dunslane.net>,
Alexander Lakhin <exclusion@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-18T17:49:46Z
Lists: pgsql-hackers
Andres Freund <andres@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
Commits
-
Try to avoid semaphore-related test failures on NetBSD/OpenBSD.
- a46311ed7214 17.3 landed
- 38da053463be 18.0 landed