Re: Non-reproducible AIO failure

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Konstantin Knizhnik <knizhnik@garret.ru>, pgsql-hackers@lists.postgresql.org

Date: 2025-06-08T18:51:11Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

aio: Stop using enum bitfields due to bad code generation
- ce161b194e84 18.0 landed
- 5865150b6d53 19 (unreleased) landed
amcheck: Fix posting tree checks in gin_index_check()
- 0cf205e122ae 18.0 cited
aio: Add missing memory barrier when waiting for IO handle
- e9a3615a5224 18.0 landed

Hi,

On 2025-06-06 15:37:45 -0400, Andres Freund wrote:
> There shouldn't be any concurrent accesses here, so I don't really see how the
> above would explain the problem (the IO can only ever be modified by one
> backend, initially the "owning backend", then, when submitted, by the IO
> worker, and then again by the backend).

The symptoms I can reproduce are slightly different than Alexander's - it's
the assertion failure reported upthread by Tom.

FWIW, I can continue to repro the assertion after removing the use of the
bitfield in PgAioHandle. So the problem indeed seems to be be independent of
the bitfields.

I'm continuing to investigate.

Greetings,

Andres Freund