Re: Non-reproducible AIO failure

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Nico Williams <nico(at)cryptonector(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 03:21:34
Message-ID: CA+hUKGJraDQyUq5BnjvU8OEH+SCvxmhCe2u98Ei9f1Q-HDLoZg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 26, 2025 at 12:45 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2025-08-25 10:43:21 +1200, Thomas Munro wrote:
> > On Mon, Aug 25, 2025 at 6:11 AM Konstantin Knizhnik <knizhnik(at)garret(dot)ru> wrote:
> > > In theory even replacing bitfield with in should not
> > > avoid race condition, because they are still shared the same cache line.
> >
> > I'm no expert in this stuff, but that's not my understanding of how it
> > works. Plain stores to normal memory go into the store buffer and are
> > eventually flushed to the memory hierarchy, but all modifications that reach
> > the cache hierarchy have a consistent view of memory created by the cache
> > coherency protocol (in ARM's case MOESI[1]): only one core can change a
> > cache line at a time while it has exclusive access (with some optimisations,
> > owner mode, snooping, etc but AFAIK that doesn't change the basic
> > consistency).
>
> From what I understand that's not quite right - the whole point of the store
> buffer is to avoid the latency hit of having to wait for cacheline
> ownership. Instead the write is done into the store buffer, notably on a
> granularity *smaller* than the cacheline (it has to be smaller, because we
> don't have the contents of the cacheline). The reason that that is somewhat
> OK from a coherency perspective is that this is done only for pure writes, not
> read-modify-write operations. As the write overwrites the prior contents of
> the memory, it is "ok" to do the write without waiting for cacheline ownership
> ahead of time.

*confused* Where's the contradiction?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-08-26 03:26:16 Re: [PATCH] no table rewrite when set column type to constrained domain
Previous Message Yugo Nagata 2025-08-26 02:55:34 Re: Improve error message for duplicate labels in enum types