Re: additional patch for contrib/tablefunc - added to

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

In response to

Responses

Browse pgsql-patches by date

  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