Re: [HACKERS] WITH RECURSIVE patch V0.1
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] WITH RECURSIVE patch V0.1 |
Дата | |
Msg-id | 14960.1211740414@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] WITH RECURSIVE patch V0.1 (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: [HACKERS] WITH RECURSIVE patch V0.1
|
Список | pgsql-patches |
[ catching up on back email ] Gregory Stark <stark@enterprisedb.com> writes: > "Yoshiyuki Asaba" <y-asaba@sraoss.co.jp> writes: >> 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. This whole thread seems to be proposing more and more complicated solutions for what is really a non-problem given Yoshiyuki-san's point. It's trivial to construct SQL queries that will run for longer than the MTBF of your hardware --- eg, forget a few join constraints. We've gotten along fine with nothing but query cancel and statement_timeout for that, and I've seen no one proposing that we need to "fix it". We don't disallow you from writing an infinite loop in plpgsql, either. I think this patch is plenty complicated enough without adding useless restrictive options. regards, tom lane
В списке pgsql-patches по дате отправления: