Horton

Re: Non-reproducible AIO failure

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Konstantin Knizhnik <knizhnik@garret.ru>, pgsql-hackers@lists.postgresql.org
Date: 2025-06-08T19:15:43Z
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 →

  1. aio: Stop using enum bitfields due to bad code generation

  2. amcheck: Fix posting tree checks in gin_index_check()

  3. aio: Add missing memory barrier when waiting for IO handle

Andres Freund <andres@anarazel.de> writes:
> 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 noticed that the assertion you and I are seeing is also about
a bitfield:

TRAP: failed Assert("aio_ret->result.status != PGAIO_RS_UNKNOWN"), File: "bufmgr.c", Line: 1605, PID: 79322

typedef struct PgAioResult
{
...
	/* of type PgAioResultStatus, see above */
	uint32		status:PGAIO_RESULT_STATUS_BITS;
...
} PgAioResult;

That doesn't make a lot of sense to me, because as far as I've
seen the bitfields in PgAioResult are not concurrently accessed.
But it feels like a relevant observation.

			regards, tom lane