"Alvaro Herrera" <alvherre@commandprompt.com> writes:
> Gregory Stark wrote:
>
>> I switched the code over to the sysv_sema style api. It's gotten a bit grotty
>> and I would clean it up if it weren't a temporary test program. If we find a
>> real problem perhaps I should add a test case like this to the "smoke test" in
>> ipc_test.c so people can check their OS.
>
> So did you discover anything? I ran your test program and it worked
> successfully for several different configurations. Not enough times
> maybe, though.
I haven't been able to find any kernel problem which would explain the
timeouts. The test program seems to work fine on all the machines I've tested
it on except one where it turned up seemingly unrelated (and far worse)
problems.
But looking over the old test results from other machines I can see occasional
transaction response times which exactly match the deadlock_timeout even
though there should be no deadlocks. Apparently this happens with older
releases of Postgres too.
So I am fairly stumped here. There's really no way I can see where we would
have the deadlock signal handler firing, not doing anything, but causing a
semaphore wait to return.
I've updated the kernel and will be running more benchmarks with the updated
kernel next week. But I don't expect the results to change.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
