Re: additional patch for contrib/tablefunc - added to

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: additional patch for contrib/tablefunc - added to
Date: 2002-09-27 01:29:57
Message-ID: Pine.LNX.4.21.0209271126560.1221-100000@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Thu, 26 Sep 2002, Joe Conway wrote:

> Gavin Sherry wrote:
> > 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.
>
> No, look at expected/tablefunc.out:
>
> -- recursion detection
> INSERT INTO connectby_int VALUES(10,9);
> INSERT INTO connectby_int VALUES(11,10);
> INSERT INTO connectby_int VALUES(9,11);
> -- should fail due to infinite recursion
> SELECT * FROM connectby('connectby_int', 'keyid', 'parent_keyid', '2', 0, '~')
> AS t(keyid int, parent_keyid int, level int, branch text);
> ERROR: infinite recursion detected
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Unless I'm miss-understanding you?

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.

Gavin

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2002-09-27 03:47:08 Re: Cascaded Column Drop
Previous Message Joe Conway 2002-09-27 01:28:45 Re: additional patch for contrib/tablefunc - added to