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

Thomas Munro

Attachment: replication-strip-volatile.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to