After upgrading to the latest patch level: PostgreSQL 8.4.2 on
i386-portbld-freebsd8.0
I have got a different core dump
(gdb) bt
#0 0x328b1068 in malloc () from /lib/libc.so.7
#1 0x082f1be9 in load_tzoffsets ()
#2 0x080aa5ef in btrescan ()
#3 0x082db80c in FunctionCall2 ()
#4 0x080a4c15 in index_rescan ()
#5 0x080a44a2 in index_getprocid ()
#6 0x080aa662 in btgetbitmap ()
#7 0x082db759 in FunctionCall3 ()
#8 0x080a4f03 in index_endscan ()
#9 0x080a4f84 in index_insert ()
#10 0x08193881 in ExecIndexRestrPos ()
#11 0x34f14af8 in ?? ()
#12 0x37715f40 in ?? ()
#13 0x00000002 in ?? ()
#14 0x37da5e58 in ?? ()
#15 0x37da51f8 in ?? ()
#16 0x37da51fc in ?? ()
#17 0x37da5200 in ?? ()
#18 0x00000000 in ?? ()
#19 0x00000000 in ?? ()
#20 0x00000100 in ?? ()
#21 0x355a5c88 in ?? ()
#22 0x00000002 in ?? ()
#23 0x00000000 in ?? ()
#24 0xbfa00608 in ?? ()
#25 0x0818382b in ExecInitNode ()
which gave me an idea to tune "max_stack_depth". I increased it four
times from 2MB to 8MB and tried to run my test query: "select
instr(ad_parent_tree(?,?),'|'||?||'|') AS isItsOwnChild from dual;"
Execution was successful without segfault, but it took 25 seconds to get
a result.
Regards, Oleg
Tom Lane wrote:
> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>
>> Still, even though the code is preposterous, the result shouldn't be a
>> segfault. I wasn't able to reproduce one myself (using 8.3.7 on
>> freebsd 7.2) however.
>>
>
> Yeah, for me it also recurses till the exception is hit, and then
> processes that successfully. This is effectively identical to a case
> in the standard regression tests, which also intentionally recurses
> till stack overflow. Since we have FreeBSD machines in the buildfarm,
> it is reasonably safe to conclude that this isn't a generic FreeBSD
> bug. I suspect the OP has used some unusual configure/build option
> or linked in some nonstandard code that is causing the available
> stack space to change unexpectedly.
>
> regards, tom lane
>
