Hi all! 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
