"Alvaro Herrera" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
