Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?

2004-08-06 Thread Manfred Koizar
On Sat, 31 Jul 2004 21:24:33 -0400, Tom Lane [EMAIL PROTECTED] wrote: Exactly. There's a proof-of-concept test at the bottom of regress/sql/plpgsql.sql, wherein a function gets control back from a query that would have run for an unreasonably long time. referring to | -- we assume this will

Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?

2004-08-06 Thread Tom Lane
Manfred Koizar [EMAIL PROTECTED] writes: referring to | -- we assume this will take longer than 1 second: | select count(*) into x from tenk1 a, tenk1 b, tenk1 c; Maybe SELECT sleep('0:0:2'::interval); as used in regress/sql/stats.sql is a better way to ensure that the query

Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?

2004-08-06 Thread Manfred Koizar
On Fri, 06 Aug 2004 18:55:49 -0400, Tom Lane [EMAIL PROTECTED] wrote: You think there's a serious risk of failure there ;-) ? Not on my hardware... Servus Manfred ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an

Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?

2004-07-31 Thread Bruce Momjian
You are asking if a funciton itself might want to set query cancel and catch the cancel and do something else? For 7.5 I would be happy just canceling the entire thing. --- Tom Lane wrote: Now that it is possible for

Re: [HACKERS] Trapping QUERY_CANCELED: yes, no, maybe?

2004-07-31 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: You are asking if a funciton itself might want to set query cancel and catch the cancel and do something else? Exactly. There's a proof-of-concept test at the bottom of regress/sql/plpgsql.sql, wherein a function gets control back from a query that would