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. For comparison, the parallel regression tests will probably fail if you can't support twenty concurrent sessions, and nobody's seriously advocated cutting that. One point worth noting is that the failing machines are running on IA64 or PPC64, and some of them seem to be only failing in some branches. So maybe there is some platform-specific effect here that could be fixed with a narrow hack. I'm not too hopeful though. Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers