On Sun, Mar 4, 2018 at 4:46 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > Thanks! Here are a couple of patches. I'm not sure which I prefer. > The "pessimistic" one looks simpler and is probably the way to go, but > the "optimistic" one avoids doing an extra read until it has actually > run out of data and seen mq_detached == true. > > I realised that the pg_write_barrier() added to > shm_mq_detach_internal() from the earlier demonstration/hack patch was > not needed... I had a notion that SpinLockAcquire() might not include > a strong enough barrier (unlike SpinLockRelease()), but after reading > s_lock.h I think it's not needed (since you get either TAS() or a > syscall-based slow path, both expected to include a full fence). I > haven't personally tested this on a weak memory order system.
The optimistic approach seems a little bit less likely to slow this down on systems where barriers are expensive, so I committed that one. Thanks for debugging this; I hope this fixes it, but I guess we'll see. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
