OSDN Git Service

Seems I was too optimistic in supposing that sinval's maxMsgNum could be
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 20 Jun 2008 00:24:53 +0000 (00:24 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 20 Jun 2008 00:24:53 +0000 (00:24 +0000)
commitdab421d2f0c5111f8549b90142e743b9c6e9e5e0
treef939836f451e372cb73c147bde9e94500ceafb00
parentfad153ec45299bd4d4f29dec8d9e04e2f1c08148
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.
src/backend/storage/ipc/sinvaladt.c