You say that you have an adp calling an sql select that runs for a significant length of time. Are you communicating to the user that the query may take awhile, and to not hit stop?
Why is the select taking so long?
I think you might want to look at why you have this problem; while I understand what you're talking about, and even see a certain validity in having the functionality, I wonder if that is the 'correct' solution to your problem.
It isn't correct to call the postgres backend processes held open in this way a 'zombie' -- a zombie will never go away and cannot be killed, whereas these postgres processes will indeed finish eventually.
Now, AOLserver uses pooled database connections, which by design don't go away at all. It is desireable for the postgres backends to stay up forever -- so really what we're after is a way of aborting a currently executing query, but keeping the connection open (taking the connection down and bringing it back up imposes some performance penalties, but the driver knows how to recover -- it just doesn't know how to drop the connection).
Furthermore, the driver is blocked during the query execution, so it can't do anything until the libpq query exec call returns. Using the asynchronous interface to libpq might work, if it were threadsafe, though. The synchronous call with the driver blocked prevents what you want from being implemented using the current database driver API, AFAICT. Even if the async libpq interface can be used, AFAICS AOLserver doesn't have a mechanism for signalling the driver that the client has backed out.
