From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Trapping QUERY_CANCELED: yes, no, maybe? |
Date: | 2004-08-06 22:20:08 |
Message-ID: | k4vsg0p5bcg3mmldi1j8vseb05voortjmg@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 31 Jul 2004 21:24:33 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 take longer than 1 second:
| select count(*) into x from tenk1 a, tenk1 b, tenk1 c;
On Thu, 29 Aug 2002 13:27:36 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> You mean, that the test might fail on a system that takes more than
>> ten seconds to INSERT or UPDATE a single row? I don't think this is a
>> real problem.
>
>I don't like depending on a timeout *at all* in a regression test;
>the exact value of the timeout is not particularly relevant to my
>concern about it.
Maybe
SELECT sleep('0:0:2'::interval);
as used in regress/sql/stats.sql is a better way to ensure that the
query takes longer than one second?
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-06 22:55:49 | Re: Trapping QUERY_CANCELED: yes, no, maybe? |
Previous Message | Joe Conway | 2004-08-06 20:48:51 | Re: pg_dump: could not parse ACL list |