[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [GENERAL] stack depth limit exceeded
From:       salah jubeh <s_jubeh () yahoo ! com>
Date:       2011-03-31 17:31:03
Message-ID: 216542.77858.qm () web52706 ! mail ! re2 ! yahoo ! com
[Download RAW message or body]

Hello, 

you are right I find one case in the query where I have infinite recursion 
 because the query result of 

SELECT ev_class::regclass::text as relname 
        FROM pg_rewrite WHERE oid IN ( SELECT objid FROM pg_catalog.pg_depend 
        WHERE refobjid = xxx::regclass::oid AND deptype ='n')

would be {xxx .....} which will lead to infinite calls. I have solved this issue 
and some of the tables which was causing this error is working fine now, but 
other tables still giving the same error 

 




________________________________
From: Jerry Sievers <gsievers19@comcast.net>
To: salah jubeh <s_jubeh@yahoo.com>
Cc: pgsql <pgsql-general@postgresql.org>
Sent: Thu, March 31, 2011 6:41:27 PM
Subject: Re: [GENERAL] stack depth limit exceeded

salah jubeh <s_jubeh@yahoo.com> writes:

> Hello,
>
> I have written this function which is simply returns the entities which depends 
>on a certain entity. It works fine if the
> dependency tree is not long. However, If I have an entity which are linked to 
>many other entities I get
>
> stack depth limit exceeded
> HINT:  Increase the configuration parameter "max_stack_depth", after ensuring 
>the platform's stack depth limit is adequate.
>
> I wrote this function to know exactly what are the tables, views that will be 
>doped if I use cascade option.  I want to get
> around this issue without changing the server configuration

[snip]

I'd strongly suspect a case of infinite recursion.  Have you ruled that
out first?>

You might try incrementing a sequence in the function during one of the
bad runs to see how deep it's recursing.

-- 
Jerry Sievers
Postgres DBA/Development Consulting
e: gsievers19@comcast.net
p: 305.321.1144

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Attachment #3 (text/html)]

<html><head><style type="text/css"><!-- DIV {margin:0px;} \
--></style></head><body><div style="font-family:arial, helvetica, \
sans-serif;font-size:10pt"><div style="color: black; font-family: arial, helvetica, \
sans-serif; font-size: 10pt; "></div><div><div><div align="center"><br><div \
style="text-align: -webkit-auto;"><font class="Apple-style-span" face="arial, \
helvetica, sans-serif" size="2">Hello,&nbsp;</font></div><div style="text-align: \
-webkit-auto;"><font class="Apple-style-span" face="arial, helvetica, sans-serif" \
size="2"><br></font></div><div style="text-align: -webkit-auto;"><font \
class="Apple-style-span" face="arial, helvetica, sans-serif" size="2">you are right I \
find one case in the query where I have&nbsp;infinite&nbsp;recursion &nbsp;because \
the query result of&nbsp;</font></div><div style="text-align: -webkit-auto;"><font \
class="Apple-style-span" face="arial, helvetica, sans-serif" \
                size="2"><br></font></div><div style="text-align:
 -webkit-auto;"><font class="Apple-style-span" face="arial, helvetica, sans-serif" \
size="2"><span class="Apple-style-span" style="font-size: 13px; ">SELECT \
ev_class::regclass::text as relname&nbsp;<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; \
FROM pg_rewrite WHERE oid IN ( SELECT objid FROM \
pg_catalog.pg_depend&nbsp;<br>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; WHERE refobjid = \
xxx::regclass::oid AND deptype ='n')</span></font></div><font \
class="Apple-style-span" face="arial, helvetica, sans-serif" size="2"><div \
align="center"><font class="Apple-style-span" face="arial, helvetica, sans-serif" \
size="2"><br></font></div><div align="center" style="text-align: left;"><font \
class="Apple-style-span" face="arial, helvetica, sans-serif" size="2">would be \
{</font>xxx .....}&nbsp;which&nbsp;will lead to&nbsp;infinite&nbsp;calls. I have \
solved this issue and some of the tables which was causing this error is working fine \
now, but other tables still giving the same  error&nbsp;</div><div align="center" \
style="text-align: left;"><font class="Apple-style-span" face="arial, helvetica, \
sans-serif" size="2"><br></font></div><div style="text-align: \
left;">&nbsp;</div></font></div></div></div><div style="color: black; font-family: \
arial, helvetica, sans-serif; font-size: 10pt; "><br></div><div style="font-family: \
arial, helvetica, sans-serif; font-size: 10pt; color: black; "><br><div \
style="font-family:arial, helvetica, sans-serif;font-size:13px"><font size="2" \
face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Jerry \
Sievers &lt;gsievers19@comcast.net&gt;<br><b><span style="font-weight: \
bold;">To:</span></b> salah jubeh &lt;s_jubeh@yahoo.com&gt;<br><b><span \
style="font-weight: bold;">Cc:</span></b> pgsql \
&lt;pgsql-general@postgresql.org&gt;<br><b><span style="font-weight: \
bold;">Sent:</span></b> Thu, March 31, 2011 6:41:27 PM<br><b><span \
style="font-weight: bold;">Subject:</span></b> Re:  [GENERAL] stack depth limit \
exceeded<br></font><br> salah jubeh &lt;<a ymailto="mailto:s_jubeh@yahoo.com" \
href="mailto:s_jubeh@yahoo.com">s_jubeh@yahoo.com</a>&gt; writes:<br><br>&gt; \
Hello,<br>&gt;<br>&gt; I have written this function which is simply returns the \
entities which depends on a certain entity. It works fine if the<br>&gt; dependency \
tree is not long. However, If I have an entity which are linked to many other \
entities I get<br>&gt;<br>&gt; stack depth limit exceeded<br>&gt; HINT:&nbsp; \
Increase the configuration parameter "max_stack_depth", after ensuring the platform's \
stack depth limit is adequate.<br>&gt;<br>&gt; I wrote this function to know exactly \
what are the tables, views that will be doped if I use cascade option.&nbsp; I want \
to get<br>&gt; around this issue without changing the server \
configuration<br><br>[snip]<br><br>I'd strongly suspect a case of infinite \
recursion.&nbsp; Have you ruled that<br>out first?&gt;<br><br>You might try \
incrementing a sequence in the function during  one of the<br>bad runs to see how \
deep it's recursing.<br><br>-- <br>Jerry Sievers<br>Postgres DBA/Development \
Consulting<br>e: <a ymailto="mailto:gsievers19@comcast.net" \
href="mailto:gsievers19@comcast.net">gsievers19@comcast.net</a><br>p: \
305.321.1144<br><br>-- <br>Sent via pgsql-general mailing list (<a \
ymailto="mailto:pgsql-general@postgresql.org" \
href="mailto:pgsql-general@postgresql.org">pgsql-general@postgresql.org</a>)<br>To \
make changes to your subscription:<br><span><a target="_blank" \
href="http://www.postgresql.org/mailpref/pgsql-general">http://www.postgresql.org/mailpref/pgsql-general</a></span><br></div></div><div \
style="position: fixed; color: black; font-family: arial, helvetica, sans-serif; \
font-size: 10pt; "></div>


</div></body></html>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic