Re: IO worker crash in test_aio/002_io_workers - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: IO worker crash in test_aio/002_io_workers
Date
Msg-id CA+hUKGKN87Rn89UgprGcrnwW+Ok6dbbM2b275O9cdtCbAZtvRw@mail.gmail.com
Whole thread Raw
In response to IO worker crash in test_aio/002_io_workers  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Jul 9, 2025 at 8:45 AM Andres Freund <andres@anarazel.de> wrote:
>                         /* Got one.  Clear idle flag. */
>                         io_worker_control->idle_worker_mask &= ~(UINT64_C(1) << MyIoWorkerId);
>
>                         /* See if we can wake up some peers. */
>                         nwakeups = Min(pgaio_worker_submission_queue_depth(),
>                                                    IO_WORKER_WAKEUP_FANOUT);
>                         for (int i = 0; i < nwakeups; ++i)
>                         {
>                                 if ((worker = pgaio_choose_idle_worker()) < 0)
>                                         break;
>                                 latches[nlatches++] = io_worker_control->workers[worker].latch;
>                         }
>
> can return a worker that's actually not currently running and thus does not
> have a latch set.

Ugh, right, thanks.  Annoyingly, I think I had already seen and
understood this while working on the dynamic worker pool sizing
patch[1] which starts and stops workers more often, and that patch of
course had to address that problem, but I somehow failed to spot or
maybe just remember that master needs that change too.  Will fix.

> I suspect the reason that this was hit with Tomas' patch is that it adds use
> of streaming reads to index scans, and thus makes it plausible at all to hit
> AIO in the path.

Cool, been meaning to try that out...

[1]
https://www.postgresql.org/message-id/flat/CA%2BhUKG%2Bm4xV0LMoH2c%3DoRAdEXuCnh%2BtGBTWa7uFeFMGgTLAw%2BQ%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Horribly slow pg_upgrade performance with many Large Objects
Next
From: Hannu Krosing
Date:
Subject: Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)