Re: Regression tests fail on OpenBSD due to low semmns value
От | Tom Lane |
---|---|
Тема | Re: Regression tests fail on OpenBSD due to low semmns value |
Дата | |
Msg-id | 1890330.1734326594@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Regression tests fail on OpenBSD due to low semmns value (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: Regression tests fail on OpenBSD due to low semmns value
|
Список | 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
В списке pgsql-hackers по дате отправления: