On Sat, Oct 30, 2010 at 10:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > A few days ago I added a regression test that involves a plpgsql > function calling a sql function, which recurses back to the plpgsql > function, etc, to a depth of 10 cycles (ie 10 plpgsql function calls > and 10 sql function calls). There are three buildfarm members that > are failing with "stack depth limit exceeded" errors on this test. > What should we do about that? Possibilities include: > > 1. Back off the recursion nesting depth of the test to whatever > it takes to get those buildfarm critters happy. > > 2. Lobby the buildfarm owners to increase their ulimit -s settings. > > 3. Chisel things enough to get the case to pass, eg by reducing the > no-doubt-generous value of STACK_DEPTH_SLOP. > > I don't especially care for choice #1. To me, one of the things that > the regression tests ought to flag is whether a machine is so limited > that "reasonable" coding might fail. If you can't do twenty or so > levels of function call you've got a mighty limited machine.
Agreed. So how much stack space does 10 or 20 nested calls actually use? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
