On Sat, Mar 24, 2012 at 1:01 PM, Michael Tautschnig m...@debian.org wrote:
Here, the two writes on Worker 0 corresponds to lines 15 and 16. And indeed
line 16 is exactly the call to SetLatch. For solving problem 1, the mp idiom,
the following options are possible (in all cases stronger
Hi,
[...]
Placing a sync (i.e., the strongest Power barrier) accordingly would,
however,
still be insufficient for the second problem, as it would only fix the
reordering of read-read pairs by Worker 1 and the store atomicity issue from
Worker 0. But the writes on Worker 0 could still
Hi again,
[...]
However, your example is enough unlike the actual code that the
conclusion you state following the word clearly isn't actually clear
to me. According to latch.h, the correct method of using a latch is
like this:
* for (;;)
* {
* ResetLatch();
* if
On Wed, Feb 29, 2012 at 10:18 AM, Michael Tautschnig m...@debian.org wrote:
In [3] it was suggested to fix the problem by placing a barrier in ResetLatch,
which corresponds to placing it between lines 11 and 12 in the code above.
This
amounts to placing a barrier between the two reads (lines
Hi all,
[Bcc'ed Tom Lane as he had done the initial investigation on this.]
Following up on the earlier discussions in
[1] http://archives.postgresql.org/pgsql-hackers/2010-11/msg01575.php
and
[2] http://archives.postgresql.org/pgsql-hackers/2011-08/msg00330.php
with an initial fix in
[3]
