Thread: Interrupting Cursors
Are there any plans to introduce the ability to 'interrupt' cursors?
We have some large queries that the user may have set off inadvertently, and it may be handy to have the ability to send an interrupt to the engine.
We have some large queries that the user may have set off inadvertently, and it may be handy to have the ability to send an interrupt to the engine.
On Mon, May 22, 2006 at 06:04:46PM +0100, Steve Tucknott wrote: > Are there any plans to introduce the ability to 'interrupt' cursors? > We have some large queries that the user may have set off inadvertently, > and it may be handy to have the ability to send an interrupt to the > engine. Would pg_cancel_backend() work? Or could you set statement_timeout to a reasonable value for certain users? http://www.postgresql.org/docs/8.1/interactive/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL-TABLE http://www.postgresql.org/docs/8.1/interactive/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-STATEMENT -- Michael Fuhr
Michael,
Looks as though it may well do. I'll see if I can get the pid of the process and give it a go.
Thanks.
On Mon, 2006-05-22 at 11:27 -0600, Michael Fuhr wrote:
On Mon, May 22, 2006 at 06:04:46PM +0100, Steve Tucknott wrote: > Are there any plans to introduce the ability to 'interrupt' cursors? > We have some large queries that the user may have set off inadvertently, > and it may be handy to have the ability to send an interrupt to the > engine. Would pg_cancel_backend() work? Or could you set statement_timeout to a reasonable value for certain users? http://www.postgresql.org/docs/8.1/interactive/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL-TABLE http://www.postgresql.org/docs/8.1/interactive/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-STATEMENT
| Regards, Steve Tucknott ReTSol Ltd DDI: 01903 828769 Mobile: 0773 671 5772 |
On Mon, May 22, 2006 at 06:47:20PM +0100, Steve Tucknott wrote: > Looks as though it may well do. I'll see if I can get the pid of the > process and give it a go. "SELECT * FROM pg_stat_activity" might be useful for obtaining the pid, especially if you have stats_command_string enabled. On Unix-like systems the output from "ps" might also be helpful. -- Michael Fuhr
Michael,
Thanks for the pointers - we use Linux so I had thought of just using ps - but I'll also look into the pg_stat_activity table and see what's in that ...
Thanks again.
On Mon, 2006-05-22 at 11:55 -0600, Michael Fuhr wrote:
Thanks for the pointers - we use Linux so I had thought of just using ps - but I'll also look into the pg_stat_activity table and see what's in that ...
Thanks again.
On Mon, 2006-05-22 at 11:55 -0600, Michael Fuhr wrote:
On Mon, May 22, 2006 at 06:47:20PM +0100, Steve Tucknott wrote: > Looks as though it may well do. I'll see if I can get the pid of the > process and give it a go. "SELECT * FROM pg_stat_activity" might be useful for obtaining the pid, especially if you have stats_command_string enabled. On Unix-like systems the output from "ps" might also be helpful.
| Regards, Steve Tucknott ReTSol Ltd DDI: 01903 828769 Mobile: 0773 671 5772 |
On Mon, May 22, 2006 at 07:10:39PM +0100, Steve Tucknott wrote: > Thanks for the pointers - we use Linux so I had thought of just using ps > - but I'll also look into the pg_stat_activity table and see what's in > that ... pg_stat_activity is a view. To learn more about it and monitoring in general see the "Monitoring Database Activity" chapter in the documentation. http://www.postgresql.org/docs/8.1/interactive/monitoring.html -- Michael Fuhr