Seems I was too optimistic in supposing that sinval's maxMsgNum could be
Tom Lane <tgl@sss.pgh.pa.us>
Seems I was too optimistic in supposing that sinval's maxMsgNum could be read and written without a lock. The value itself is atomic, sure, but on processors with weak memory ordering it's possible for a reader to see the value change before it sees the associated message written into the buffer array. Fix by introducing a spinlock that's used just to read and write maxMsgNum. (We could do this with less overhead if we recognized a concept of "memory access barrier"; is it worth introducing such a thing? At the moment probably not --- I can't measure any clear slowdown from adding the spinlock, so this solution is probably fine.) Per buildfarm results.
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/storage/ipc/sinvaladt.c | modified | +48 −15 |