While playing with the array stuff earlier, I noticed this (using a 
non-array example to be sure it wasn't related to anything unique to my 
development environment):

regression=# create function int4(varchar) returns int4 as 'select 
int4($1)' language 'sql';
CREATE FUNCTION
regression=# select int4('a'::varchar);
The connection to the server was lost. Attempting reset: Failed.
connection pointer is NULL

I also reproduced it on a 7.3.2 machine.

Granted, in retrospect it's a pretty brain-dead thing to do ;-), but it 
seems the system should protect me better from myself. Below is the 
first few lines of the backtrace -- it must be recursing, because I 
stopped looking at 6500 or so frames.

BTW, what I was trying to do was create a function with the same name 
but different input types as an internal function (e.g. I wanted to make 
array_append(int4[], int4) using array_append(anyarray, anyelement)). I 
thought there was a way to do that, but obviously this isn't it. Any 
suggestions?

Joe

Program received signal SIGSEGV, Segmentation fault.
yyparse () at y.tab.c:8997
8997    y.tab.c: No such file or directory.
         in y.tab.c
(gdb) bt
#0  yyparse () at y.tab.c:8997
#1  0x080c1a03 in raw_parser (str=0xd4a1034 "select int4($1)") at 
parser.c:55
#2  0x08159f13 in pg_parse_query (query_string=0xd4a1034 "select 
int4($1)") at postgres.c:454
#3  0x08133b71 in inline_function (funcid=2150312, result_type=23, 
args=0xd49fb40, func_tuple=0x402d7d80, active_fns=0x0)
     at clauses.c:1754
#4  0x08133971 in simplify_function (funcid=2150312, result_type=23, 
args=0xd49fb40, allow_inline=1 '\001', active_fns=0x0)
     at clauses.c:1585
#5  0x081338c1 in eval_const_expressions_mutator (node=0xd49f9f8, 
active_fns=0x0) at clauses.c:1036
#6  0x08134727 in expression_tree_mutator (node=0xd49fa50, 
mutator=0x8133188 <eval_const_expressions_mutator>, context=0x0)
     at clauses.c:2657
#7  0x08133223 in eval_const_expressions_mutator (node=0xd49fa50, 
active_fns=0x0) at clauses.c:1546
#8  0x08134be3 in expression_tree_mutator (node=0xd49fa6c, 
mutator=0x8133188 <eval_const_expressions_mutator>, context=0x0)
     at clauses.c:2677
#9  0x08133223 in eval_const_expressions_mutator (node=0xd49fa6c, 
active_fns=0x0) at clauses.c:1546
#10 0x08133184 in eval_const_expressions (node=0xd49fa6c) at clauses.c:1009
#11 0x0812c755 in preprocess_expression (parse=0xd49f7f0, 
expr=0xbf7fff10, kind=1) at planner.c:377
#12 0x0812c503 in subquery_planner (parse=0xd49f7f0, tuple_fraction=0) 
at planner.c:226
#13 0x0812c3d0 in planner (parse=0xd49f7f0, isCursor=0 '\0', 
cursorOptions=0) at planner.c:118
#14 0x0815a0be in pg_plan_query (querytree=0xd49f7f0) at postgres.c:574
#15 0x080fe404 in init_execution_state (src=0xd49f548 "select int4($1)", 
argOidVect=0xd49f52c, nargs=1) at functions.c:111
#16 0x080fe591 in init_sql_fcache (finfo=0xd49f268) at functions.c:232
#17 0x080fecb3 in fmgr_sql (fcinfo=0xbf800890) at functions.c:468
#18 0x080faf95 in ExecMakeFunctionResult (fcache=0xd49f25c, 
econtext=0xd49f1d8, isNull=0xbf8009bb "", isDone=0xd49f4e4)
     at execQual.c:856
#19 0x080fc3c3 in ExecEvalExpr (expression=0xd49f25c, 
econtext=0xd49f1d8, isNull=0x80 <Address 0x80 out of bounds>,
     isDone=0xbf7fff10) at execQual.c:2010
#20 0x080fcdb7 in ExecTargetList (targetlist=0xd49f3a0, 
targettype=0xd49f3bc, econtext=0xd49f1d8, values=0xd49f4ac,
     nulls=0xd49f4c8 "\177~", '\177' <repeats 14 times>, "ï¿½ï¿½G\r\020", 
itemIsDone=0xd49f4e4, isDone=0xbf800a1c)
     at execQual.c:2715
#21 0x080fcf98 in ExecProject (projInfo=0xbf7fff10, isDone=0xbf800a1c) 
at execQual.c:2859
#22 0x08103b32 in ExecResult (node=0xd49f14c) at nodeResult.c:155
#23 0x080f9b01 in ExecProcNode (node=0xd49f14c) at execProcnode.c:296
#24 0x080f8679 in ExecutePlan (estate=0xd49f02c, planstate=0xd49f14c, 
operation=CMD_SELECT, numberTuples=1,
     direction=-1082127844, dest=0x8259d80) at execMain.c:1021
#25 0x080f7ad7 in ExecutorRun (queryDesc=0xd49dd58, 
direction=ForwardScanDirection, count=1) at execMain.c:228
#26 0x080fe71e in postquel_getnext (es=0xd49dd00) at functions.c:277
#27 0x080fe8df in postquel_execute (es=0xd49dd00, fcinfo=0xbf800bd0, 
fcache=0xd49d4f8) at functions.c:370
#28 0x080feb2d in fmgr_sql (fcinfo=0xbf800bd0) at functions.c:493
#29 0x080faf95 in ExecMakeFunctionResult (fcache=0xd49d254, 
econtext=0xd49d1d0, isNull=0xbf800cfb "", isDone=0xd49d4dc)


Mon, 26 May 2003 20:50:32 -0700
Joe Conway <mail@joeconway.com>
SIGSEGV on cvs tip/7.3.2
Joe Conway <mail@joeconway.com> writes:
> Granted, in retrospect it's a pretty brain-dead thing to do ;-), but it 
> seems the system should protect me better from myself.

There's been some past speculation about putting in a function call
nesting depth limit, but I haven't been able to think of any reasonable
way to estimate a safe limit.  The stack size limit varies a lot across
different platforms, and the amount of stack space consumed per PL
function call level seems hard to estimate too.  We do have a nesting
depth limit for expressions, which is intended specifically to avoid
stack overflow during expression eval --- but the amount of stack chewed
per expression level is relatively small and predictable.

			regards, tom lane

Tue, 27 May 2003 10:07:05 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: SIGSEGV on cvs tip/7.3.2 
> There's been some past speculation about putting in a function call
> nesting depth limit, but I haven't been able to think of any reasonable
> way to estimate a safe limit.  The stack size limit varies a lot across
> different platforms, and the amount of stack space consumed per PL
> function call level seems hard to estimate too.  We do have a nesting
> depth limit for expressions, which is intended specifically to avoid
> stack overflow during expression eval --- but the amount of stack chewed
> per expression level is relatively small and predictable.

GUC variable?  Hmm...but that would mean that a normal user could still just
crash the machine...?

Chris


Wed, 28 May 2003 10:11:58 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: SIGSEGV on cvs tip/7.3.2 
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> There's been some past speculation about putting in a function call
>> nesting depth limit, but I haven't been able to think of any reasonable
>> way to estimate a safe limit.

> GUC variable?  Hmm...but that would mean that a normal user could still just
> crash the machine...?

Yeah, which makes it a bit pointless :-(.  Too bad there's not any
portable way to get some behavior other than SIGSEGV for stack overflow.

			regards, tom lane

Wed, 28 May 2003 14:38:50 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: SIGSEGV on cvs tip/7.3.2 