Re: Deadlock detection

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Daniel Migowski <dmigowski(at)ikoffice(dot)de>, PostgreSQL - JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Deadlock detection
Date: 2009-01-22 00:19:28
Message-ID: 4977BB90.8090806@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Simon Riggs wrote:
> On Wed, 2009-01-21 at 13:17 +0100, Daniel Migowski wrote:
>
>> I don't know if there is a more elegant way to handle this, but for us
>> it works. Maybe for you, too. As far as i know (which is not much
>> about the driver internals) this is the only way to make the driver
>> hang.
>
> Thank you. This seems like simple, practical advice.
>
> My "watcher" ideas seem like they would take too long and at best would
> only identify a problem, not solve it. Thanks to those that helped out
> there also.
>
> If the only known way of making the driver hang is running out of
> buffers then the best way to react is to increase the buffer allocation.

Well, the problem is that there's no "right" value for the buffer size
with the current strategy. The default works for all but the most
extreme cases (like Daniel's 100,000 INSERTs), but raising the default
just means that you need a larger set of queries to trigger it.

I have vague memories that another way to trigger the deadlock was to
have a relatively small number of queries that generated a lot of
NOTIFYs or, perhaps, server warning messages? Can't remember the
details, but it was an unusual case involving triggers.

I have a bit of time spare today, I might look at putting together that
OutputStream wrapper.

-O

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Oliver Jowett 2009-01-22 01:16:45 Re: Deadlock detection
Previous Message Simon Riggs 2009-01-22 00:16:50 Re: Deadlock detection