additional patch for contrib/tablefunc - added to regression test
The attached adds a bit to the contrib/tablefunc regression test for behavior
of connectby() in the presence of infinite recursion. Please apply this one in
addition to the one sent earlier.
Thanks,
Joe
Attachments:
contrib-tablefunc-regr.1.patchtext/plain; name=contrib-tablefunc-regr.1.patchDownload+59-0
Joe,
This test presumes that it will succeed. That is, if there is an infinite
recursion here, the test will just hang -- as far as I can tell -- and
will not *actually* report the failure.
Gavin
On Thu, 26 Sep 2002, Joe Conway wrote:
Show quoted text
The attached adds a bit to the contrib/tablefunc regression test for behavior
of connectby() in the presence of infinite recursion. Please apply this one in
addition to the one sent earlier.Thanks,
Joe
Gavin Sherry wrote:
Correct me if i'm wrong: there was a but in connectby which meant that it
did not detect infinite recursion correct. You want to add a test to make
sure it continues to do so. 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.
Thanks for pointing that out! New patch will be sent in shortly -- gotta fight
traffic now.
Joe
Import Notes
Reference msg id not found: Pine.LNX.4.21.0209271126560.1221-100000@linuxworld.com.au | Resolved by subject fallback
Joe Conway <mail@joeconway.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