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

From Thomas Munro
Subject Re: Non-reproducible AIO failure
Date
Msg-id CA+hUKGKBegb+pmv0Z05KBPmVuxJnU=STLz=49Lto0FgWFYLxYg@mail.gmail.com
Whole thread Raw
In response to Re: Non-reproducible AIO failure  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Mon, Aug 25, 2025 at 2:41 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Mon, Aug 25, 2025 at 1:52 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > >         struct { PgAioHandleState v:8; } state;
> >
> > This preserves type safety and compiles to strb two properties we
> > want, but it seems to waste space (look at the offsets for the
> > stores):
> >
> > a.out[0x1000005f8] <+140>: ldr    x8, [sp, #0x8]
> > a.out[0x1000005fc] <+144>: strb   wzr, [x8, #0x8]
> > a.out[0x100000600] <+148>: ldr    x8, [sp, #0x8]
> > a.out[0x100000604] <+152>: strb   wzr, [x8, #0x4]
>
> Sorry, I didn't make that very clear: that's open source clang 17
> compiling assignment of zero to two neighbouring wrapped bitfields
> with your trick.  Probably easier to look at the struct layout with
> pahole or printf offsetof(...) or sizeof() to see that PgAioHandle
> grows by 9 bytes of padding, something Andres obviously felt pretty
> strongly about if he felt the need to summon bitfields...

(Errm, surely more than 9 due to alignment of the following stuff, I
was just looking at a truncated test struct with only those bits...)



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Non-reproducible AIO failure
Next
From: Chao Li
Date:
Subject: Re: Identifying function-lookup failures due to argument name mismatches