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