Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vHoZs-0028qj-4l for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Nov 2025 19:26:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vHoZo-002mvZ-Uf for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Nov 2025 19:26:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vHoZo-002mvR-Ko for pgsql-hackers@lists.postgresql.org; Sat, 08 Nov 2025 19:26:20 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vHoZm-0066gk-2X for pgsql-hackers@postgresql.org; Sat, 08 Nov 2025 19:26:19 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5A8JQEfE1496142; Sat, 8 Nov 2025 14:26:15 -0500 From: Tom Lane To: Thomas Munro cc: Alexander Lakhin , Andres Freund , pgsql-hackers , greg@burd.me Subject: Re: IO in wrong state on riscv64 In-reply-to: <1340546.1762561464@sss.pgh.pa.us> References: <60bbebf4-0a80-4e5f-83c0-311c85f6bd5c@gmail.com> <927941c8-e5a1-4787-bbd9-88f0d92b55d0@gmail.com> <1338407.1762560226@sss.pgh.pa.us> <1340546.1! 762561464@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Fri, 07 Nov 2025 19:24:24 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1496140.1762629974.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 08 Nov 2025 14:26:14 -0500 Message-ID: <1496141.1762629974@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ... BTW, I wonder why you did not add pg_compiler_barrier_impl() to our other use of __atomic_thread_fence: #if !defined(pg_memory_barrier_impl) # if defined(HAVE_GCC__ATOMIC_INT32_CAS) # define pg_memory_barrier_impl() __atomic_thread_fence(__AT= OMIC_SEQ_CST) # elif defined(__GNUC__) # define pg_memory_barrier_impl() __sync_synchronize() # endif #endif /* !defined(pg_memory_barrier_impl) */ If the problem is that Clang doesn't treat __atomic_thread_fence as a compiler barrier, why is this usage safer than the other two? regards, tom lane