Re: Maximum function call nesting depth for regression tests
От | Tom Lane |
---|---|
Тема | Re: Maximum function call nesting depth for regression tests |
Дата | |
Msg-id | 13089.1288588349@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Maximum function call nesting depth for regression tests (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Maximum function call nesting depth for regression tests
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Sat, Oct 30, 2010 at 10:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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? I just did some testing with git HEAD on RHEL-5 machines (gcc 4.1.2). It appears the actual stack consumption for one cycle (plpgsql to sql back to plpgsql) is 4112 bytes on ia64, 4000 bytes on ppc32, 8256 bytes on ppc64. Of course these numbers could be expected to vary some depending on compiler version and options, but 4K to 8K looks like the expected number. Now the odd thing about this is that we're not running up against the actual kernel stack limit, because we're not dumping core. What we're hitting is the max_stack_depth check; and the reason that is odd is that we *never* set max_stack_depth to less than 100kB, no matter what insane reading we might get from getrlimit. So it seems like there should be enough room for 10 of these cycles, certainly so on the ia64 machine although maybe ppc64 is marginal. So I'm back to suspecting funny business on the buildfarm machines. Just for the record, this is the call stack cycle we're talking about: #0 plpgsql_call_handler (fcinfo=0x60000fffffcbf9b0) at pl_handler.c:100 #1 0x40000000003ae660 in ExecMakeFunctionResult (fcache=0x60000000001e6180, econtext=0x60000000001e5fc8, isNull=0x60000000001e6bc8"\177~\177\177\177\177\177\177\bW'", isDone=0x60000000001e6d08) at execQual.c:1836 #2 0x40000000003a4c70 in ExecTargetList (projInfo=<value optimized out>, isDone=0x60000fffffcbfd60) at execQual.c:5110 #3 ExecProject (projInfo=<value optimized out>, isDone=0x60000fffffcbfd60) at execQual.c:5325 #4 0x40000000003e36d0 in ExecResult (node=<value optimized out>) at nodeResult.c:155 #5 0x40000000003a3b10 in ExecProcNode (node=0x60000000001e5eb0) at execProcnode.c:361 #6 0x40000000003d64f0 in ExecLimit (node=0x60000000001e5b70) at nodeLimit.c:89 #7 0x40000000003a3e50 in ExecProcNode (node=0x60000000001e5b70) at execProcnode.c:480 #8 0x40000000003a0630 in ExecutePlan (queryDesc=<value optimized out>, direction=<value optimized out>, count=1) at execMain.c:1236 #9 standard_ExecutorRun (queryDesc=<value optimized out>, direction=<value optimized out>, count=1) at execMain.c:282 #10 0x40000000003c15b0 in postquel_getnext (fcinfo=0x60000fffffcbfe00) at functions.c:475 #11 fmgr_sql (fcinfo=0x60000fffffcbfe00) at functions.c:704 #12 0x40000000003ae660 in ExecMakeFunctionResult (fcache=0x60000000001dde80, econtext=0x60000000001ddc58, isNull=0x60000000001df1a0"\177~\177\177\177\177\177\177\030\356#", isDone=0x60000000001df2e0) at execQual.c:1836 #13 0x40000000003a4c70 in ExecTargetList (projInfo=<value optimized out>, isDone=0x60000fffffcc01b0) at execQual.c:5110 #14 ExecProject (projInfo=<value optimized out>, isDone=0x60000fffffcc01b0) at execQual.c:5325 #15 0x40000000003e36d0 in ExecResult (node=<value optimized out>) at nodeResult.c:155 #16 0x40000000003a3b10 in ExecProcNode (node=0x60000000001ddb40) at execProcnode.c:361 #17 0x40000000003a0630 in ExecutePlan (queryDesc=<value optimized out>, direction=<value optimized out>, count=2) at execMain.c:1236 #18 standard_ExecutorRun (queryDesc=<value optimized out>, direction=<value optimized out>, count=2) at execMain.c:282 #19 0x40000000003fdc40 in _SPI_execute_plan (plan=<value optimized out>, paramLI=0x60000000001afb60, snapshot=0x0, crosscheck_snapshot=0x0, read_only=0 '\000', fire_triggers=<value optimized out>, tcount=2) at spi.c:2092 #20 0x40000000003fe5e0 in SPI_execute_plan_with_paramlist ( plan=0x600000000020767c, params=0x60000000001afb60, read_only=0'\000', tcount=2) at spi.c:423 #22 0x2000000006193820 in exec_eval_expr (estate=0x60000fffffcc05a8, expr=0x6000000000204480, isNull=0x60000fffffcc05b8"\001", rettype=0x60000fffffcc05bc) at pl_exec.c:4222 #23 0x200000000619fbf0 in exec_stmt (estate=0x60000fffffcc05a8, stmts=<value optimized out>) at pl_exec.c:2148 #24 exec_stmts (estate=0x60000fffffcc05a8, stmts=<value optimized out>) at pl_exec.c:1239 #25 0x20000000061a1a30 in exec_stmt_if (estate=0x60000fffffcc05a8, stmt=<value optimized out>) at pl_exec.c:1479 #26 0x200000000619dd00 in exec_stmt (estate=0x60000fffffcc05a8, stmts=<value optimized out>) at pl_exec.c:1288 #27 exec_stmts (estate=0x60000fffffcc05a8, stmts=<value optimized out>) at pl_exec.c:1239 #28 0x200000000619c810 in exec_stmt_block (estate=0x60000fffffcbf9b0, block=0x0) at pl_exec.c:1177 #29 0x20000000061a3660 in plpgsql_exec_function (func=0x60000000001547c8, fcinfo=0x60000fffffcc09c0) at pl_exec.c:317 #30 0x2000000006186ae0 in plpgsql_call_handler (fcinfo=0x10000) at pl_handler.c:122 #31 0x40000000003ae660 in ExecMakeFunctionResult (fcache=0x60000000001cd230, econtext=0x60000000001cd078, I haven't looked to see if any of these have an excessive amount of local variables. regards, tom lane
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Robert HaasДата:
Сообщение: Re: SR fails to send existing WAL file after off-line copy
Следующее
От: Heikki LinnakangasДата:
Сообщение: Re: SR fails to send existing WAL file after off-line copy