Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
Gregory Stark wrote: Joshua D. Drake [EMAIL PROTECTED] 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 -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
Hans-Juergen Schoenig wrote: Gregory Stark wrote: Joshua D. Drake [EMAIL PROTECTED] writes: 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. I don't think we need to add clutter to GUC for something that exists to handle the problem at hand. If our real concern is server utilization based on user or query resources we need to look at an overall solution for that issue not a one off for a single feature. Sincerely, Joshua D. Drake -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
[ catching up on back email ] Gregory Stark [EMAIL PROTECTED] writes: Yoshiyuki Asaba [EMAIL PROTECTED] 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 -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: Updated patch (Re: [PATCHES] WITH RECURSIVE patch V0.1)
On Sat, May 24, 2008 at 05:08:51AM -0700, David Fetter wrote: On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote: WITH RECURSIVE patch V0.1 Please find updated patch with bug fixes from Yoshiyuki Asaba and Michael Meskes. Any mistakes in it are mine. :) As promised, the mistakes were mine, and I did not include Asaba-san's fix. :P Please find enclosed another patch remedying this problem and documenting some of what WITH [RECURSIVE] does. I'm also thinking there should be updates to psql's \h and tab completion code. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate recursive_query-3.patch.gz Description: GNU Zip compressed data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] LOCK_DEBUG documentation
Greg Sabino Mullane [EMAIL PROTECTED] writes: Documentation patch by Kevin L. McBride explaining LOCK_DEBUG options in detail. Should this stuff really go into the SGML documentation, when these options will certainly never be enabled anywhere except in developers' private builds? A few lines of comments in pg_config_manual.h seems a more appropriate solution. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
