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
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
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 w
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 wo
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 plpg
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 e
