Re: Non-reproducible AIO failure - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Non-reproducible AIO failure
Date
Msg-id bad72acd-fac7-4444-b81c-ed4c9b62505f@garret.ru
Whole thread Raw
In response to Re: Non-reproducible AIO failure  (Dmitry Mityugov <dmitry.mityugov@gmail.com>)
Responses Re: Non-reproducible AIO failure
List pgsql-hackers
On 03/09/2025 8:37 PM, Dmitry Mityugov wrote:
> Quite inspiring discussion. The patch is brilliantly good but it adds 
> a bunch of explicit type casts, and it's not always easy to remember 
> what cast to use in a particular case, and that may eventually lead to 
> errors in the future. Just wanted to add that when 64-bit code is 
> generated, uint8s are probably aligned to 64-bit boundaries for 
> structures that contain other 64-bit members like pointers, and bit 
> fields are not (and they may not have an address at all). To align bit 
> fields properly, anonymous bit fields probably can be used, or unions 
> containing the bitfields together with uint8s, to avoid the explicit 
> casts, like in this example:
>
> struct Foo {
>     union {
>         char a:8;
>         char aa;
>     };
>     char b:8;
>     int* c;
> };
>
> Regards,
>

Size of PgAioHandle is144 bytes. I wonder how critical for us is to save 
9 bytes for it (3 bytes vs 3 integers)?
Why not to use normal enums instead of bitfields and uint8 with type casts?





pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Should io_method=worker remain the default?
Next
From: Nathan Bossart
Date:
Subject: Re: Improve LWLock tranche name visibility across backends