Re: [PATCHES] WITH RECURSIVE patch V0.1 - Mailing list pgsql-hackers

From Hans-Juergen Schoenig
Subject Re: [PATCHES] WITH RECURSIVE patch V0.1
Date
Msg-id 48395B42.6070102@cybertec.at
Whole thread Raw
In response to Re: [PATCHES] WITH RECURSIVE patch V0.1  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: [PATCHES] WITH RECURSIVE patch V0.1  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Gregory Stark wrote:
> "Joshua D. Drake" <jd@commandprompt.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


pgsql-hackers by date:

Previous
From: "Stephen R. van den Berg"
Date:
Subject: Re: [PERFORM] Posible planner improvement?
Next
From: Alvaro Herrera
Date:
Subject: Re: DROP ROLE dependency tracking ...