Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] WITH RECURSIVE patch V0.1

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Yoshiyuki Asaba <y-asaba(at)sraoss(dot)co(dot)jp>, david(at)fetter(dot)org, zb(at)cybertec(dot)at, ishii(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] WITH RECURSIVE patch V0.1
Date: 2008-05-25 12:27:46
Message-ID: 48395B42.6070102@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Gregory Stark wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>
>   
>>>>> Couldn't we just have it pay attention to the existing
>>>>> max_stack_depth?
>>>>>           
>>>> Recursive query does not consume stack. The server enters an infinite
>>>> loop without consuming stack. Stack-depth error does not happen.
>>>>         
>>> We could have a separate guc variable which limits the maximum number of
>>> levels of recursive iterations. That might be a useful feature for DBAs that
>>> want to limit their users from issuing an infinite query.
>>>       
>> statement_timeout :)
>>     
>
> Good point.
>
> Though it occurs to me that if you set FETCH_COUNT in psql (or do the
> equivalent in your code ) statement_timeout becomes much less useful.
>
>   

i don't think statement_timeout is a good idea at all.
it is not deterministic. depending on the load on the server some 
queries will execute while others fail.
a separate GUC is needed.

    best regards,

       hans



-- 
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql-support.de, www.postgresql-support.com


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-05-25 12:56:49
Subject: Re: DROP ROLE dependency tracking ...
Previous:From: Stephen R. van den BergDate: 2008-05-25 08:21:33
Subject: Re: [PERFORM] Posible planner improvement?

pgsql-patches by date

Next:From: Joshua D. DrakeDate: 2008-05-25 18:30:50
Subject: Re: [HACKERS] WITH RECURSIVE patch V0.1
Previous:From: Dickson S. GuedesDate: 2008-05-24 14:09:47
Subject: Re: TODO item: Have psql show current values for a sequence

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group