Re: IO in wrong state on riscv64
| От | Thomas Munro |
|---|---|
| Тема | Re: IO in wrong state on riscv64 |
| Дата | |
| Msg-id | CA+hUKGJt82c69MwXwxCnYJTJadMmmtVqeZnApQCJPoVyOOZR1A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: IO in wrong state on riscv64 (Thomas Munro <thomas.munro@gmail.com>) |
| Ответы |
Re: IO in wrong state on riscv64
|
| Список | 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 по дате отправления: