Hi, On 2025-03-18 18:53:48 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > To allow the number of IO workers to be increased without a restart, we need > > to reserve PGPROC entries for the workers unconditionally. This has been > > judged to be worth the cost. If it turns out to be problematic, we can > > introduce a PGC_POSTMASTER GUC to control the maximum number. > > So I see this patch added 32 PGPROCs and hence 32 semaphores to the > system's requirements.
Yea - I brought that suspicion up a few times in the thread and in the resulting discussion it wasn't deemed worth introducing a PGC_POSTMASTER guc to control the max. > It's probably time to just abandon the idea of being able to run with > only 60 semaphores. Agreed. It's an absurdly outdated OS default configuration. Realistically one can't run postgres even in a toy scenario without changing it. So the value of being able to test postgres with the default OS settings doesn't seem that high. If it were on a very commonly used platform I would think differently, but net/openbsd ain't that. > I wonder though if we ought to revert 38da05346 and/or 6d0154196 in view of > that. 38da05346 doesn't seem to have much value if it doesn't help us run the tests by default - but it also doesn't really hurt. So, shrug, I guess. 6d0154196 - a higher autovacuum_worker_slots increases resource usage more than IO workers do, because autovac workers are included in computations like lock space. But 16 isn't that much either way... Greetings, Andres Freund
