From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | PostgreSQL - JDBC <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Deadlock detection |
Date: | 2009-01-21 11:30:40 |
Message-ID: | 1232537440.2327.365.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Wed, 2009-01-21 at 23:38 +1300, Oliver Jowett wrote:
> Simon Riggs wrote:
>
> > If not, other suggestions and viewpoints welcome. Thanks,
>
> If you want a minimally invasive approach (in terms of rewriting driver
> code) and some extra overhead isn't a problem then I would suggest
> something like this:
...
> The obvious costs of this are the extra thread per connection, the
> context switches needed to actually do the writes, and however much
> space you need for all the write buffers.
Thanks very much for such a detailed design.
I'd like to identify situations where deadlocks occur so we can fix
them, or confirm they haven't happened at all.
I think your proposal would work, but sounds fairly invasive. I'm
concerned that if we interfere with the main line of processing we'll
just introduce a new set of bugs that won't move us forwards. I would
prefer a "watcher" approach, which doesn't directly interfere with the
main line of processing and can be turned on/off. Perhaps it isn't
possible?
How about a watcher thread that waits for main thread to respond, if no
response within a timeout it wakes. We then pass information to another
agent which can compare against server-side information and identify
deadlocks. A client/server deadlock detector, rather than within the
driver as I described before.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2009-01-21 11:38:50 | Re: Deadlock detection |
Previous Message | Oliver Jowett | 2009-01-21 10:48:55 | Re: Deadlock detection |