Skip site navigation (1) Skip section navigation (2)

Re: BUG #1473: Backend bus error, possibly due to ANALYZE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: "Brian B(dot)" <brian-pgsql(at)bbdab(dot)org>,pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #1473: Backend bus error, possibly due to ANALYZE
Date: 2005-02-10 15:08:14
Message-ID: 26668.1108048094@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2005-02-10 15:29:54
Subject: Re: pg_dump table ordering bug [8.0.1]
Previous:From: Tom LaneDate: 2005-02-10 15:01:16
Subject: Re: BUG #1473: Backend bus error, possibly due to ANALYZE

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group