Re: Deadlock detection

On Thu, 22 Jan 2009, Oliver Jowett wrote:

> Kris Jurka wrote:
>>
>> On Thu, 22 Jan 2009, Oliver Jowett wrote:
>>>
>>> This passes the regression testsuite with antiDeadlock=true, but I don't
>>> have a deadlock testcase on hand to try unfortunately.
>>>
>>
>> This has a test case which deadlocks consistently:
>>
>> http://archives.postgresql.org/pgsql-jdbc/2008-10/msg00045.php
>
> Perfect, thanks
>
> My changes seem to pass BatchDeadLock with antiDeadlock=true (and still
> hang with antiDeadlock=false):

I'm not really sure what to do with this code. It does two different
things and what is does best really wasn't the thrust of this thread.

1) It avoids deadlocks by buffering the writes in local memory. That's
great, but wasn't really the point of the thread. Would we suggest people
run with antiDeadlock=true in a production environment to avoid deadlocks?
If so, why wouldn't it be the default.

2) It warns when a deadlock has potentially occurred with stack trace
information to provide the call location. That's good, but it can't be
100% accurate. With a small timeout it may warn when there wouldn't be an
actual deadlock and with a large timeout it may not warn when the call
would have deadlocked without the intermediate buffer. Having the
intermediate buffer means that you aren't testing the same thing, so a
success with antiDeadlock=true has no implications as to whether your
application will deadlock with it turned off. Previously it was discussed
that you'd really want to cap the buffer size, so perhaps relating the
maximum buffer size to Socket.getSendBufferSize might make the results of
testing with antiDeadlock more representative of the behavior with it
turned off.

So it's a useful piece of code, but I'm not sure what context it should
really be used in. Is anyone using this? For what purpose?

Kris Jurka