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 05:45:18
Message-ID: 19312.1090820718@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:
> surely postgres should stop the select if the client
> dissapears in a puff of smoke?

The current design intention is that the backend will notice loss of
connection when it next tries to receive a command from the client
--- and not before. You could argue that a SELECT is side-effect
free and can be aborted arbitrarily, but I wouldn't agree, because
the SELECT could be invoking a user-defined function that does have
side effects. If we were to abort upon noticing that the output data
didn't seem to be going anywhere, then the behavior would be both
timing-dependent and platform-dependent.

> ... we end up with a postgres SELECT thread running at 99% cpu
> time on our backend.

If the SELECT is taking more CPU than it otherwise would, then that
might represent a bug we oughta fix. But I don't think that finishing
out a requested SELECT is in and of itself a bug.

regards, tom lane

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Dave Page 2004-07-26 14:11:27 Re: problem with CVS version
Previous Message Joe Conway 2004-07-24 02:13:33 Re: Linux ODBC (MS SQL Server driver)