Race conditions in shm_mq.c

From: Antonin Houska <ah(at)cybertec(dot)at>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Race conditions in shm_mq.c
Date: 2015-08-06 14:10:34
Message-ID: 19862.1438870234@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

During my experiments with parallel workers I sometimes saw the "master" and
worker process blocked. The master uses shm queue to send data to the worker,
both sides nowait==false. I concluded that the following happened:

The worker process set itself as a receiver on the queue after
shm_mq_wait_internal() has completed its first check of "ptr", so this
function left sender's procLatch in reset state. But before the procLatch was
reset, the receiver still managed to read some data and set sender's procLatch
to signal the reading, and eventually called its (receiver's) WaitLatch().

So sender has effectively missed the receiver's notification and called
WaitLatch() too (if the receiver already waits on its latch, it does not help
for sender to call shm_mq_notify_receiver(): receiver won't do anything
because there's no new data in the queue).

Below is my patch proposal.

--
Antonin Houska
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at

Attachment Content-Type Size
shm_mq_race.patch text/x-diff 1.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-08-06 14:27:52 Re: Raising our compiler requirements for 9.6
Previous Message Uriy Zhuravlev 2015-08-06 13:36:21 Re: Performance improvement for joins where outer side is unique