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?
> Perhaps it would be worth considering representing IN lists as a
> distinct expression type, at least in the parser. Then the
> transformExpr() code would look like:
> foreach (element of IN list)
> transformExpr(element);
> ... do whatever else ...
> so we wouldn't need to recurse. We could then transform the new
> expression type into a list of OR clauses at this point.
Waste of time unless you were to propagate this representation all the
way through; as described above you'd merely be postponing the stack
depth problem to a later phase.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
