On Thu, Aug 28, 2008 at 1:42 AM, Francisco Figueiredo Jr.
<francisco@npgsql.org> 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