Re: Automatically sizing the IO worker pool - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Automatically sizing the IO worker pool
Date
Msg-id CA+hUKG+tng_nk1_sMzb5ThTuqDy+ERES270_=kcNiZnbDP-u1A@mail.gmail.com
Whole thread
In response to Re: Automatically sizing the IO worker pool  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Apr 8, 2026 at 2:20 PM Andres Freund <andres@anarazel.de> wrote:
> I don't follow.  What I was proposing is after the conditional lock
> acquisition succeeded.  So is your nsync == 0 check.

Oops.  Sorry, brainfade.  Condition removed.

> > +/*
> > + * Tell postmaster that we think a new worker is needed.
> > + */
> > +static void
> > +pgaio_worker_request_grow(void)
> > +{
> > +     /*
> > +      * Suppress useless signaling if we already know that we're at the
> > +      * maximum.  This uses an unlocked read of nworkers, but that's OK for
> > +      * this heuristic purpose.
> > +      */
> > +     if (io_worker_control->nworkers < io_max_workers)
> >       {
> > -             io_worker_control->workers[i].latch = NULL;
> > -             io_worker_control->workers[i].in_use = false;
> > +             if (!io_worker_control->grow)
> > +             {
> > +                     io_worker_control->grow = true;
> > +                     pg_memory_barrier();
> > +
> > +                     /*
> > +                      * If the postmaster has already been signaled, don't do it again
> > +                      * until the postmaster clears this flag.  There is no point in
> > +                      * repeated signals if grow is being set and cleared repeatedly
> > +                      * while the postmaster is waiting for io_worker_launch_interval
> > +                      * (which it applies even to canceled requests).
> > +                      */
> > +                     if (!io_worker_control->grow_signal_sent)
> > +                     {
> > +                             io_worker_control->grow_signal_sent = true;
> > +                             pg_memory_barrier();
> > +                             SendPostmasterSignal(PMSIGNAL_IO_WORKER_GROW);
> > +                     }
> > +             }
> >       }
> >  }
>
>
> I'd probbly use early returns to make it a bit more readable.

Done for this and similar functions.

> > +static bool
> > +pgaio_worker_can_timeout(void)
> > +{
> > +     PgAioWorkerSet workerset;
> > +
> > +     /* Serialize against pool size changes. */
> > +     LWLockAcquire(AioWorkerControlLock, LW_SHARED);
> > +     workerset = io_worker_control->workerset;
> > +     LWLockRelease(AioWorkerControlLock);
> > +
> > +     if (MyIoWorkerId != pgaio_workerset_get_highest(&workerset))
> > +             return false;
> > +
> > +     if (MyIoWorkerId < io_min_workers)
> > +             return false;
> > +
> > +     return true;
> > +}
>
> I guess I'd move the < io_min_workers to earlier so that you don't acquire the
> lock if that'll return false anyway.

Done.

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] Fix minRecoveryPoint not advanced past checkpoint in CreateRestartPoint
Next
From: "David G. Johnston"
Date:
Subject: doc: Improve wal_level and effective_wal_level GUC around logical replication