On Thu, Aug 28, 2008 at 1:42 AM, Francisco Figueiredo Jr. <francisco@xxxxxxxxxx> wrote: > Hi all! > Any clues about this? Thanks in advance. > I'm playing with client thread abort issues in Npgsql. And with a test > sample one of our users provided us we are seeing that even after the > client finishes its processing, I'm seeing some stalled server > processes processing the query. > > The problem is that those server processes seem not to die when the > client disconnects. Even worse, if I try to stop server, because of > then, the server can't shutdown. > > Have you seen something like that? Is it possible that I can mess up > with frontend protocol so that the server process keeps waiting for > something? > > What is strange is that even after the socket is closed, the server > process is still there. > > Also, I'd like to ask what is the best way of handling an abrupt > client abortion. On my tests I'm doing the following: I'm sending a > cancelrequest message followed by closing the socket. I know this > isn't the most elegant way of doing it. For me the ideal would be to > clear the protocol from any garbage the abrupt interruption may let it > and return the connection to our internal pool. But I don't have any > idea about how to clear the protocol state other than send the > cancelrequest and try to "eat" any still existent byte in the stream > until I receive an errorresponse or readyforquery (in case the query > was successfully executed before the cancelrequest) But this approach > may lead me to read up too much bytes before cleaning the protocol, or > am I missing something? > > > > > I'm using Postgresql 8.3.3 on OSX 10.5.4 > > Thanks in advance for any advice about this issue. > > > > -- > Regards, > > Francisco Figueiredo Jr. > http://fxjr.blogspot.com > http://www.npgsql.org > -- Regards, Francisco Figueiredo Jr. http://fxjr.blogspot.com http://www.npgsql.org
