From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Regression tests fail on OpenBSD due to low semmns value |
Date: | 2024-12-16 05:23:14 |
Message-ID: | 1890330.1734326594@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Lakhin <exclusion(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2024-12-16 05:57:34 | Re: Added schema level support for publication. |
Previous Message | Michael Paquier | 2024-12-16 05:14:55 | Re: pg_combinebackup PITR comparison test fix |