On Tue, Jun 18, 2024 at 07:43:36PM -0500, Nathan Bossart wrote:
> On Tue, Jun 18, 2024 at 02:33:31PM -0700, Andres Freund wrote:
>> Another one:
>>
>> Have a general cap of 64, but additionally limit it to something like
>> max(1, min(WORKER_CAP, max_connections / 4))
>>
>> so that cases like tap tests don't end up allocating vastly more worker slots
>> than actual connection slots.
>
> That's a clever idea. My only concern would be that we are tethering two
> parameters that aren't super closely related, but I'm unsure whether it
> would cause any problems in practice.
Here is an attempt at doing this. I've added 0001 [0] and 0002 [1] as
prerequisite patches, which helps simplify 0003 a bit. It probably doesn't
work correctly for EXEC_BACKEND builds yet.
I'm still not sure about this approach. At the moment, I'm leaning towards
something more like v2 [2] where the upper limit is a PGC_POSTMASTER GUC
(that we would set very low for TAP tests).
[0] https://commitfest.postgresql.org/48/4998/
[1] https://commitfest.postgresql.org/48/5059/
[2] https://postgr.es/m/20240419154322.GA3988554%40nathanxps13
--
nathan
