From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: additional patch for contrib/tablefunc - added to |
Date: | 2002-09-27 04:03:39 |
Message-ID: | 20789.1033099419@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Joe Conway <mail(at)joeconway(dot)com> writes:
> Gavin Sherry wrote:
>> ... However, if you bust the infinite recursion
>> detection it will, by definition, recurse infinitely and not elog() -- at
>> least in a reasonably time frame.
>>
>> To handle this situation, you may need to use the psql timeout
>> functionality -- but I know nothing about it.
> I think you finally got through my thick skull. Now I see the
> issue. OK, I'll rework the patch using a timeout.
I think this is unnecessary. Bugs in any functionality tested by a
regression test could cause the system to go into an infinite loop;
but we don't put timeouts on all of them. In practice we rely on
the user to exercise some judgment about whether the tests are
proceeding normally.
I think a timeout is more likely to create problems than fix them;
how will you pick a platform-independent, system-load-independent
timeout value, for example?
Also, in my experience an infinite-recursion bug generally results
in a pretty quick stack overflow and core dump, so a timeout per se
wouldn't be needed anyway.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2002-09-27 04:09:40 | Re: additional patch for contrib/tablefunc - added to |
Previous Message | Bruce Momjian | 2002-09-27 04:00:47 | Re: Cascaded Column Drop |