From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Christian <davidc(at)comtechmobile(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Server hangs on multiple connections |
Date: | 2002-09-20 17:34:06 |
Message-ID: | 24787.1032543246@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
David Christian <davidc(at)comtechmobile(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2002-09-20 17:35:08 | Bug #777: postgresql desconectado (not connect) |
Previous Message | David Christian | 2002-09-20 17:03:57 | Re: Server hangs on multiple connections |