Should pointers to PGPROC be volatile-qualified? - Mailing list pgsql-hackers

From Tom Lane
Subject Should pointers to PGPROC be volatile-qualified?
Date
Msg-id 20817.1189017680@sss.pgh.pa.us
Whole thread Raw
Responses Re: Should pointers to PGPROC be volatile-qualified?
List pgsql-hackers
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 */
TransactionIdpxid = 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: loose ends in lazy-XID-assigment patch
Next
From: Andrew Dunstan
Date:
Subject: Re: loose ends in lazy-XID-assigment patch