From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Nico Williams <nico(at)cryptonector(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, rmt(at)lists(dot)postgresql(dot)org |
Subject: | Re: Non-reproducible AIO failure |
Date: | 2025-08-26 00:37:17 |
Message-ID: | o5y7dzugxpaidihm6z3qixuwz6cvz7nodqqhjdjoyk7lkudwv4@hjomnlzlt3ns |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I'm a bit confused by this focus on bitfields - both Alexander and Konstantin
stated they could reproduce the issue without the bitfields.
But we have observed the generated code being pretty grotty and it's caused
more than enough confusion - so let's just replace them with plain uint8's and
cast in switches.
> I think the issue is that if the compiler decides to coalesce what we
> think of as distinct (but neighboring) bitfields, then when you update
> one of the bitfields you could be updating the other with stale data
> from an earlier read where the cached stale data is cached in a
> _register_. Thus the fact that the cache line should have the most up
> to date data for that other field is irrelevant because the stale data
> is in a _register_.
>
> The very fact that this can happen, that the C specs allow it, argues
> that one must never have adjacent distinct (for some value of
> "distinct") bitfields for anything that requires atomics.
I think the barriers in place should prevent that.
Greetings,
Andres Freund
Attachment | Content-Type | Size |
---|---|---|
v1-0001-aio-Stop-using-enum-bitfields-due-to-bad-code-gen.patch | text/x-diff | 5.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-08-26 00:37:34 | Re: Parallel heap vacuum |
Previous Message | Sami Imseih | 2025-08-26 00:37:05 | Re: Improve LWLock tranche name visibility across backends |