| 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
| 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. |