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: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-16T05:23:14Z
Lists: pgsql-hackers
Alexander Lakhin <exclusion@gmail.com> writes: > I deployed OpenBSD 7.4 locally and reproduced "too many clients" and that > hang as well. It turned out that OpenBSD has semmns as low as 60 (see [4]) > and as a consequence, initdb sets max_connections = 20 for the regression > test database. (This can be helpful sometimes, see e.g., [5].) At the same > time, paralell_schedule contains groups of 20 tests, for instance: Yeah. That was more-or-less okay before we invented parallel query, but now there needs to be some headroom. I've thought about adjusting initdb to not allow max_connections less than 25 (can't remember if I actually proposed that on-list though). The other way would be to rearrange parallel_schedule to make the max group size less than 20, but that seems like a lot of effort for little benefit. FTR, NetBSD also has unreasonably tiny semaphore settings out-of-the box. mamba's host is using kern.ipc.semmni=100 kern.ipc.semmns=1000 and for that matter kern.maxvnodes=60000 kern.maxproc=1000 kern.maxfiles=10000 > ... > So GetSafeSnapshot() waits indefinitely for possibleUnsafeConflicts to > become empty (for other backend to remove itself from the list of possible conflicts > inside ReleasePredicateLocks()), but it doesn't happen. This seems like an actual bug? regards, tom lane
Commits
-
Try to avoid semaphore-related test failures on NetBSD/OpenBSD.
- a46311ed7214 17.3 landed
- 38da053463be 18.0 landed