Question on io_min_workers > io_max_workers semantics

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Question on io_min_workers > io_max_workers semantics
Date: 2026-05-07 11:50:40
Message-ID: CABPTF7U0wzdGcNUxtwxO9p86k3p0KoEJWZQBKg+Ve8pAiDtfqA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Thomas, Hackers,

While looking at d1c01b79d4ae (aio: Adjust I/O worker pool
automatically), I had a question about the intended semantics for
io_min_workers > io_max_workers.

Both GUCs currently have independent 1..MAX_IO_WORKERS range checks,
so a configuration such as:

io_min_workers = 32 io_max_workers = 1

is accepted. In maybe_start_io_workers_scheduled_at(), the
io_max_workers check comes first, so io_max_workers effectively caps
the minimum:

if (io_worker_count >= io_max_workers) return 0;
if (io_worker_count < io_min_workers) return TIMESTAMP_MINUS_INFINITY;

Is that intended? If so, should we document that the effective minimum
is capped by io_max_workers, or perhaps emitting a warning similar to
the autovacuum_max_workers / autovacuum_worker_slots case?

--
Best,
Xuneng

Browse pgsql-hackers by date

  From Date Subject
Next Message Nisha Moond 2026-05-07 11:53:58 Re: Proposal: Conflict log history table for Logical Replication
Previous Message shveta malik 2026-05-07 11:46:23 Re: Include schema-qualified names in publication error messages.