Re: Maximum function call nesting depth for regression tests

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Maximum function call nesting depth for regression tests
Дата
Msg-id AANLkTi=17bNX8GjXZ0An6fOOeTxbLQa26fVtU7dohmYB@mail.gmail.com
обсуждение исходный текст
Ответ на Maximum function call nesting depth for regression tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Maximum function call nesting depth for regression tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, Oct 30, 2010 at 10:47 PM, Tom Lane <tgl@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


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: type info refactoring
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: ALTER OBJECT any_name SET SCHEMA name