Re: Issue about memory order on ARM - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Issue about memory order on ARM
Date
Msg-id 12778.1575215351@sss.pgh.pa.us
Whole thread Raw
In response to Issue about memory order on ARM  ("盏一" <w@hidva.com>)
List pgsql-hackers
"=?utf-8?B?55uP5LiA?=" <w@www.hidva.com> writes:
> The code in GetSnapshotData() that read the `xid` field of  PGXACT struct has a dependency on code in
GetNewTransactionId()that write `MyPgXact->xid`. It means that the store of xid should happen before the load of it.
InC11, we can use [Release-Acquire
ordering](https://en.cppreference.com/w/c/atomic/memory_order#Release-Acquire_ordering)to achieve it. But now, there is
nospecial operation to do it(, and the [volatile](https://en.cppreference.com/w/c/language/volatile) keyword should not
playany role in this situation). 
> So it means that when a backend A returns from GetNewTransactionId(), the newval of `MyPgXact->xid` maybe just in
CPUstore buffer, or CPU cache line, so the newval is not yet visible to backend B that calling GetSnapshotData(). So
theassumption that 'all top-level XIDs <= latestCompletedXid are either present in the ProcArray, or not running
anymore'may not be safe.  

You'e ignoring the memory barriers that are implicit in LWLock
acquisition and release; as well as the fact that it's transaction
end, not start, that needs to be interlocked.  Please read the section
"Interlocking Transaction Begin, Transaction End, and Snapshots"
in src/backend/access/transam/README.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Do we have a CF manager for November?
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum