On Thu, 2009-01-22 at 00:38 +1300, Oliver Jowett wrote:
> Simon Riggs wrote:
>
> > 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?
>
> It's not really invasive at all, you need an OutputStream implementation
> (that is completely new code and separate from the rest of the driver)
> and a small amount of setup code when first establishing the connection
> to hook it in as the stream that's actually written to. The setup code
> can be conditional. The rest of the driver doesn't change at all.
>
> > How about a watcher thread that waits for main thread to respond, if no
> > response within a timeout it wakes.
>
> That could work. Note that there is no single "main thread", it's just
> whatever application threads happen to be running queries. You would
> need to arm the watchdog before any write or flush, and disarm it before
> reading or returning to the client (via a normal return or an
> exception). If the watchdog on a particular thread stays armed for more
> than some period, you trigger a warning.
>
> It might be tricky to get useful state out of the driver when that timer
> goes off - you'll be in the wrong thread to get a useful stacktrace at
> that point, I guess you'll have to go and abruptly close the underlying
> socket to unblock the deadlocked query thread - which means you need to
> have some way to correlate threads with sockets. And you kill the
> connection by closing down the socket, obviously.
>
> Seems like it would get a bit complicated..
OK, I'll consider. Thanks for your advice.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support