Hello,
On Thu, Feb 10, 2005 at 10:08:14AM -0500, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > It seems what's happening here is that dspam is submitting a query with
> > many thousands of elements in the IN clause. In the parser, we transform
> > "foo IN (a, b, c)" into "foo = a OR foo = b OR foo = c", and then
> > recurse for each element of the OR expression and eventually run out of
> > stack space.
>
> There is a check_stack_depth call in there, so this could only be the
> explanation if max_stack_depth is set too high for the actual
> stack depth limit. What's the platform, and what ulimit values is the
> postmaster started under?
FreeBSD 4.11 on x86 using PostgreSQL 8.0.1
% limits
Resource limits (current):
cputime infinity secs
filesize 512000 kb
datasize 524288 kb
stacksize 65536 kb
coredumpsize 307200 kb
memoryuse-cur 458752 kb
memorylocked-cur 458752 kb
maxprocesses 512
openfiles 7351
sbsize infinity bytes
vmemoryuse infinity kb
max_stack_depth is at the default commented value of 2048
I can bump this value up to test it if desired, it just takes
a while to get to the point of the backend crash scenario.
I feed about 2300 good pieces of email using the dspam corpus
feed program. Around 200 email messages left to feed,
the backend will want to crash around that point. I will try
to narrow down what query is being ran at that point. Perhaps
I can extract it from the core dump.
Thanks,
Brian B.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
