Re: Apache - DBI - Postgresql: Cancelling queries - Mailing list pgsql-general

From Ian Harding
Subject Re: Apache - DBI - Postgresql: Cancelling queries
Date
Msg-id 3F2A68E7.3000907@tpchd.org
Whole thread Raw
In response to Apache - DBI - Postgresql: Cancelling queries  (Mat <psql-mail@freeuk.com>)
Responses Re: Apache - DBI - Postgresql: Cancelling queries
List pgsql-general
The "solution" I finally implemented seems to be pretty good, graying
out the button after it's pushed with javascript.  That means no more
doubleclick problem, and no more hammering away at the same button.  It
does not preclude the reloading of the page (reactivating the button) or
just going somewhere else and issuing another query.

The "real" solutions involving cute little client side applets that
phone home to the server to see if the query is still running and show a
phony status bar seem like too much work and still don't prevent
malicious wankers from issuing multiple queries.

Good luck!

Mat wrote:

>I am having trouble with users firing off a query from the web
>interface, and then getting bored of waiting and firing off a different
>query.
>
>As http is stateless apache, (and so the perl cgi script) only realises
>that the user has gone when it ties to send data back to the user and
>gets a "broken pipe" type response. This is usually too late as by this
>time the query has completed, using up valuable resources.
>
>Is there a tried and tested solution to this problem?
>If so please let me know!
>
>If not...
>
>I am working on a work around at the moment but have run into trouble!
>
>I have read the DBI man pages but there doesn't seem to be a cancel
>query function implemented, can anyone confirm or deny this?
>
>Can i send some control sequence using DBI to cancel the query?
>
>I had taken the approach of having two perl threads, one to run the
>query and one to poll the browser every second to see if the user is
>still there. Plan X was then to cancel the query if the user had ended
>the connection.
>
>The first problem was the lack of cancel query, second problem seems to
>be that the DBI database handles cannot be shared between thread - so i
>will have to pass a signal to the thread waiting for query to return to
>cancel it? anyone else tried this? any more gaping pitfalls that i
>should be aware of?!
>
>Thanks!
>
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
>



pgsql-general by date:

Previous
From: Ron Johnson
Date:
Subject: Re: plPHP -- sort of an announcement.. but not commercial
Next
From: Bhavesh Jardosh
Date:
Subject: Help with BEGIN/COMMIT within a transaction