Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c? - Mailing list pgsql-hackers

From Thomas Munro
Subject Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?
Date
Msg-id CAEepm=2f-N5MD+xYYyO=yBpC9SoOdCdrdiKia9_oLTSiu1uBtA@mail.gmail.com
Whole thread Raw
Responses Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi

In walsender.c, walreceiver.c, walreceiverfuncs.c there are several
places where volatile qualifiers are used apparently only to prevent
reordering around spinlock operations.  My understanding is that if
potential load/store reordering around spinlock operations is the only
reason for using volatile, 0709b7ee72e4bc71ad07b7120acd117265ab51d0
made it unnecessary.  For example see
6ba4ecbf477e0b25dd7bde1b0c4e07fc2da19348 which stripped some volatile
qualifiers out of xlog.c.

I did notice that sometimes walsnd->pid is read without acquiring the
spinlock.  Is that actually OK anyway (taking a stale and inconsistent
view of the contents of walsnd->pid WRT to the other members that are
later accessed while holding the spinlock)?

Would it be safe to remove all those volatile qualifiers, something
like in the attached, or am I missing something?

(There is also code in syncrep.c that is reading shmem without
acquiring spinlocks using volatile qualifiers, that is a different
situation, though I don't yet see how it is ordering sensitive or
reading the same object repeatedly, but I'm not talking about that
here).

--
Thomas Munro
http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: tsvector work with citext
Next
From: Tom Lane
Date:
Subject: Re: tsvector work with citext