Re: hanging select processes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Rogers <John(at)delosis(dot)com>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: hanging select processes
Date: 2004-07-26 14:26:45
Message-ID: 27147.1090852005@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

John Rogers <John(at)delosis(dot)com> writes:
> As for the last comment you made though, I've had a look at the load on
> the server during this simulated Access crash, and it DOES seem to me
> that the thread goes out of control afterwards. Setting up complex query
> at the access end which will repeadedly select the same view from
> postgres results in a relatively low load on the backend; but killing
> access during this same query causes the SELECT process to ramp itself
> up to 100% over the time course of a couple of seconds.

Hmm. With no network delays for delivery of output data, you could
expect the SELECT to become CPU-bound; it would just be sitting there
running the query as fast as it could. So I'm not sure that the above-
described behavior is a problem. However, if what is happening is that
it's getting stuck in an infinite loop trying and failing to output
data, then that's definitely bad. So I guess the question is: does the
backend terminate after about the same number of CPU seconds that it
would ordinarily take to process the query? Or does it seem to run
forever until killed? Also, can you stop it with "kill -INT" when it's
in this state?

regards, tom lane

In response to

Browse pgsql-odbc by date

  From Date Subject
Next Message Roderick A. Anderson 2004-07-26 23:16:55 Re: Linux ODBC (MS SQL Server driver)
Previous Message Dave Page 2004-07-26 14:11:27 Re: problem with CVS version