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

From Tom Lane
Subject Re: IO in wrong state on riscv64
Date
Msg-id 1496141.1762629974@sss.pgh.pa.us
Whole thread Raw
In response to Re: IO in wrong state on riscv64  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: IO in wrong state on riscv64
List pgsql-hackers
... 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(__ATOMIC_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



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: ago(interval) → timestamptz
Next
From: Tomas Vondra
Date:
Subject: Re: should we have a fast-path planning for OLTP starjoins?