Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 14, 2013 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, fixing that doesn't yield much joy; initdb stalls and then
crashes with
PANIC: stuck spinlock (40054a88) detected at xlog.c:2182
The reason for that is that the code
I wrote:
I'm inclined to agree that #error is the only realistic answer in
general, though we could probably go ahead with equating
pg_memory_barrier to pg_compiler_barrier on specific architectures we
know are single-processor-only. Unfortunately, that means we just
raised the bar for
On Wed, Jul 17, 2013 at 4:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This would not be hard to fix, I think.
Really? Given that the memory barrier primitives are supposed to be,
well, primitive, I don't think this is exactly a trivial problem.
There's no good place to initialize such a
On Sun, Jul 14, 2013 at 09:26:38PM -0400, Robert Haas wrote:
I'm pretty sure we've got latent memory-ordering risks in our existing
code which we just haven't detected and fixed yet. Consider, for
example, this exciting code from GetNewTransactionId:
Commit 9a20a9b2 breaks the build for me, using gcc on HPPA:
xlog.c:2182: macro `pg_memory_barrier' used without args
xlog.c:2546: macro `pg_memory_barrier' used without args
make[4]: *** [xlog.o] Error 1
The reason for this is that the fallback definition of
pg_memory_barrier has been wrong
On Sun, Jul 14, 2013 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Commit 9a20a9b2 breaks the build for me, using gcc on HPPA:
xlog.c:2182: macro `pg_memory_barrier' used without args
xlog.c:2546: macro `pg_memory_barrier' used without args
make[4]: *** [xlog.o] Error 1
The reason for this
