Re: Trapping QUERY_CANCELED: yes, no, maybe? - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: Trapping QUERY_CANCELED: yes, no, maybe?
Date
Msg-id k4vsg0p5bcg3mmldi1j8vseb05voortjmg@email.aon.at
Whole thread Raw
In response to Re: Trapping QUERY_CANCELED: yes, no, maybe?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Trapping QUERY_CANCELED: yes, no, maybe?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, 31 Jul 2004 21:24:33 -0400, Tom Lane <tgl@sss.pgh.pa.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@sss.pgh.pa.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.

MaybeSELECT 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?

ServusManfred


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: pg_dump: could not parse ACL list
Next
From: Tom Lane
Date:
Subject: Re: Trapping QUERY_CANCELED: yes, no, maybe?