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
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
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
Now that it is possible for plpgsql functions (and, no doubt, soon
others) to trap errors, I think we need a little bit of discussion
about what kind of restrictions should be put on trapping the
QUERY_CANCELED error. If we treat QUERY_CANCELED as an absolutely
ordinary error, it would be fairly
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
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
