Re: Deadlock detection

Поиск
Список
Период
Сортировка
От Oliver Jowett
Тема Re: Deadlock detection
Дата
Msg-id 4977BB90.8090806@opencloud.com
обсуждение исходный текст
Ответ на Re: Deadlock detection  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Deadlock detection
Re: Deadlock detection
Список 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

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Deadlock detection
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Deadlock detection