Reason for using write barrier before unlocking the buffer header in Postgresql I was reading the source code for buffer management in Postgres. In buffer management, there is a macro to unlock the buffer header
#define UnlockBufHdr(desc, s)   \
    do {    \
        pg_write_barrier(); \
        pg_atomic_write_u32(&amp;(desc)-&gt;state, (s) &amp; (~BM_LOCKED)); \
    } while (0)

This code clears the BM_LOCKED flag in state variable present inside buffer header atomically.
I know that pg_write_barrier() blocks the compiler from reordering loads and stores around the barrier and also ensures that the stores issued prior to the barrier are completed before
any stores issued after the barrier. This is used to remove the inconsistencies raised in SMP systems due to out of order execution.
But I am unable to see how reordering memory accesses here can be a problem. It will be of great help if someone can give me the reason for using a write barrier before the unlocking operation.
Without looking at the code, that seems not surprising to me: if you have the buffer header locked and write to it, then you want all these writes to happen before you unlock the buffer, right?