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 по дате отправления: