Re: Deadlock detection

On Thu, 2009-01-22 at 13:19 +1300, Oliver Jowett wrote:
> Simon Riggs wrote:

> > 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.

That would be good. Thanks.

There was another hang earlier today. One session just went idle in
transaction on server right in the middle of a long transaction. 1500
statements in about a second on the session, then nothing, while holding
locks. People are adamant it is not the application; much checking has
been done.

I've got this strange feeling that this happens a lot, but DBAs ignore
it as some quirk the application guys have missed. And that's why we
have calls for an idle in transaction timeout and requests to support
cancelling them. (I'm want both but I wonder about the reasons why).

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support