Maximum function call nesting depth for regression tests

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Maximum function call nesting depth for regression tests
Date: 2010-10-31 02:47:08
Message-ID: 10386.1288493228@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Boxuan Zhai 2010-10-31 04:16:14 a new problem in MERGE
Previous Message Tom Lane 2010-10-31 02:28:01 Re: Hash support for arrays