Hi,
On 2025-03-18 18:53:48 -0400, Tom Lane wrote:
> Andres Freund <andres@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
