Re: BUG #1473: Backend bus error, possibly due to ANALYZE
От | Tom Lane |
---|---|
Тема | Re: BUG #1473: Backend bus error, possibly due to ANALYZE |
Дата | |
Msg-id | 26668.1108048094@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #1473: Backend bus error, possibly due to ANALYZE (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: BUG #1473: Backend bus error, possibly due to ANALYZE
|
Список | pgsql-bugs |
Neil Conway <neilc@samurai.com> 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
В списке pgsql-bugs по дате отправления: