On Thu, Aug 28, 2008 at 1:42 AM, Francisco Figueiredo Jr.
> 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
> 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.
> Francisco Figueiredo Jr.
Francisco Figueiredo Jr.
In response to
pgsql-general by date
|Next:||From: Stanislav Raskin||Date: 2008-08-31 13:14:35|
|Subject: query with offset stops using index scan|
|Previous:||From: Thomas Finneid||Date: 2008-08-31 12:14:22|
|Subject: integer values in conf file|