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
