Re: Non-reproducible AIO failure
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Konstantin Knizhnik <knizhnik@garret.ru>
Cc: Dmitry Mityugov <dmitry.mityugov@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Nico Williams <nico@cryptonector.com>, Alexander Lakhin <exclusion@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
rmt@lists.postgresql.org
Date: 2025-09-03T19:42:06Z
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-09-03 21:50:42 +0300, Konstantin Knizhnik wrote: > On 03/09/2025 8:37 PM, Dmitry Mityugov wrote: > Size of PgAioHandle is144 bytes. I wonder how critical for us is to save 9 > bytes for it (3 bytes vs 3 integers)? Not that it makes that huge a difference, but due to alignment considerations the size increase would be 12 bytes, not 9. Maybe that could be addressed by more reordering though. > Why not to use normal enums instead of bitfields and uint8 with type casts? There are a lot of PgAioHandles when max_connections is large. In addition, some workloads (e.g. network attached storage), one might need to increase io_max_concurrency to actually be able to saturate storage. An ~8% increase in size isn't nothing when the baseline isn't small. Greetings, Andres Freund