Re: IO in wrong state on riscv64 - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: IO in wrong state on riscv64
Date
Msg-id CA+hUKGJt82c69MwXwxCnYJTJadMmmtVqeZnApQCJPoVyOOZR1A@mail.gmail.com
Whole thread Raw
In response to Re: IO in wrong state on riscv64  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: IO in wrong state on riscv64
List pgsql-hackers
On Thu, Oct 23, 2025 at 8:52 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Oh, I think this should work better:
>
> #define pg_read_barrier_impl() \
> do { pg_compiler_barrier_impl();
> __atomic_thread_fence(__ATOMIC_ACQUIRE); } while (0)

Alexander did some extensive testing and we stared at the codegen on a
lot of architectures to confirm that this prevents the reordering.
Pushed and back-patched like that.

Someone should probably write an arch-riscv.h file that generates
FENCE R, R and FENCE W, W (these are a bit weaker than what the
compiler is generating but strong enough for our "traditional
pre-C11-style" barrier semantics) and it's probably safe to declare
that RISC-V has atomic single copy for int64_t (hard to imagine this
isn't try, but we would need to cite the chapter and verse of the
technical manual).  But RISC-V was really just the messenger here, so
we had to address the generic version anyway.



pgsql-hackers by date:

Previous
From: Manni Wood
Date:
Subject: Re: [PATCH] Add pg_get_tablespace_ddl() function to reconstruct CREATE TABLESPACE statement
Next
From: Jim Jones
Date:
Subject: Re: [PATCH] Add pg_get_tablespace_ddl() function to reconstruct CREATE TABLESPACE statement