Re: pgsql: aio: Infrastructure for io_method=worker

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

Re: pgsql: aio: Infrastructure for io_method=worker

2025-03-18 Thread Nathan Bossart
On Tue, Mar 18, 2025 at 07:07:53PM -0400, Andres Freund wrote: > On 2025-03-18 18:53:48 -0400, Tom Lane wrote: >> 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 r

Re: pgsql: aio: Infrastructure for io_method=worker

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

Re: pgsql: aio: Infrastructure for io_method=worker

2025-03-18 Thread Tom Lane
Andres Freund 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 m