Should pointers to PGPROC be volatile-qualified?

There are a bunch of places where we do things like

PGPROC *proc = arrayP->procs[index];
/* Fetch xid just once - see GetNewTransactionId */
TransactionId pxid = proc->xid;

... use pxid several times ...

In the case where "use pxid" involves a function call, this is probably
safe enough, because the compiler can't assume that the called function
won't access and modify the PGPROC. However, if "use pxid" is straight
line code, I am suddenly wondering if the C compiler could think it can
get away with loading proc->xid more than once instead of expending a
register on it. As far as it knows there isn't any way for the value
to change underneath it.

The correct fix for this is probably to make the fetch happen through a
volatile-qualified pointer, eg

volatile PGPROC *proc = arrayP->procs[index];
/* Fetch xid just once - see GetNewTransactionId */
TransactionId pxid = proc->xid;

I'm wondering how far to go with that. In the extreme we could try to
make MyProc and all other PGPROC pointers volatile-qualified; is that
overkill?

Or maybe I'm worried over nothing. I can't recall any bug reports that
seem like they could be tied to such a thing, and given that we can only
set, not clear, MyProc->xid and xmin without exclusive lock, there might
not actually be a bug here. But it seems a bit risky.

Comments? Does anyone think the C standard forbids what I'm worried
about?

regards, tom lane