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

From Alexander Lakhin
Subject Re: IO in wrong state on riscv64
Date
Msg-id 927941c8-e5a1-4787-bbd9-88f0d92b55d0@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
Hello Thomas,

23.10.2025 00:51, Thomas Munro wrote:
On a more practical note, Alexander, does this work?
 #if !defined(pg_read_barrier_impl) && defined(HAVE_GCC__ATOMIC_INT32_CAS) /* acquire semantics include read barrier semantics */
-#              define pg_read_barrier_impl()
__atomic_thread_fence(__ATOMIC_ACQUIRE)
+#              define pg_read_barrier_impl()           do {
__atomic_signal_fence(__ATOMIC_ACQUIRE);
__atomic_thread_fence(__ATOMIC_ACQUIRE); } while (0) #endif

Someone might want to write an arch-riscv.h that spits out the asm
instead (should be just FENCE R, R and FENCE W, W as far as I can see,
which might be slightly better than what acquire/release generate, on
paper at least), but apparently this problem is wider than RISCV so we
need a general solution anyway.

Thank you for working on this!

Unfortunately, this change doesn't lead to change in disassembly of
pgaio_io_wait(), produced with clang-19 -O1. That is, I'm getting the same
disassembly as the one I sent you before (error/pgaio_io_wait.asm).
I tried:
 #if !defined(pg_read_barrier_impl) && defined(HAVE_GCC__ATOMIC_INT32_CAS)
 /* acquire semantics include read barrier semantics */
-#              define pg_read_barrier_impl()           __atomic_thread_fence(__ATOMIC_ACQUIRE)
+#              define pg_read_barrier_impl()           do { } while (0)
 #endif
to make sure that the change of pg_read_barrier_impl() affects
pgaio_io_wait() and really saw a difference in the disassembly.

I haven't run tests with the modified version yet, going to test later
just to be sure, but I suppose we want to see the binary code changed.

Best regards,
Alexander

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Logical Replication of sequences
Next
From: Richard Guo
Date:
Subject: Re: Issue with query_is_distinct_for() and grouping sets