Maximum function call nesting depth for regression tests

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Maximum function call nesting depth for regression tests
Дата
Msg-id 10386.1288493228@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Maximum function call nesting depth for regression tests  (Robert Haas <robertmhaas@gmail.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Hash support for arrays
Следующее
От: Boxuan Zhai
Дата:
Сообщение: a new problem in MERGE