On Sun, Mar 4, 2018 at 5:40 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> Could shm_mq_detach_internal() need a pg_write_barrier() before it
> writes mq_detached = true, to make sure that anyone who observes that
> can also see the most recent increase of mq_bytes_written?
I can reproduce both failure modes (missing tuples and "lost contact")
in the regression database with the attached Python script on my Mac.
It takes a few minutes and seems to be happen sooner when my machine
is also doing other stuff (playing debugging music...).
I can reproduce it at 34db06ef9a1d7f36391c64293bf1e0ce44a33915
"shm_mq: Reduce spinlock usage." but (at least so far) not at the
preceding commit.
I can fix it with the following patch, which writes XXX out to the log
where it would otherwise miss a final message sent just before
detaching with sufficiently bad timing/memory ordering. This patch
isn't my proposed fix, it's just a demonstration of what's busted.
There could be a better way to structure things than this.
--
Thomas Munro
http://www.enterprisedb.com
