David Christian <[EMAIL PROTECTED]> writes:
> On Friday, Sep 20, 2002, at 11:30 US/Eastern, Tom Lane wrote:
>> Another interesting line of attack would be to try compiling
>> src/backend/storage/lmgr/lwlock.c at different optimization levels,
[ and indeed the problem goes away at -O0 ]
> So, is it safe to proceed this way? If this turns out to be the
> solution, is there anything I should be aware of with regard to
> stability and performance vs. a normal install?
This should be stable; whether there's a measurable performance hit
from de-optimizing just that one file is hard to say.
At this point I would say that the problem is that the compiler's
optimizer is rearranging the order of operations inside lwlock.c
in a way that breaks the code for parallel operations. This could
be a compiler bug, or it could be that the compiler is doing something
it's allowed to do under the C specification --- in which case we need
to add some more "volatile"s to fix it.
Could you send me (off-list, since it's likely to be large) the lwlock.s
file produced by
gcc -O0 -I../../../../src/include -S lwlock.c
as well as the one produced by
gcc -O1 -I../../../../src/include -S lwlock.c
Groveling through the assembly code should at least tell me what's being
changed ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
