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

From: "John Hansen" <john(at)geeknet(dot)com(dot)au>
To: "Neil Conway" <neilc(at)samurai(dot)com>, "Brian B(dot)" <brian-pgsql(at)bbdab(dot)org>
Cc: "pgsql-bugs" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #1473: Backend bus error, possibly due to ANALYZE
Date: 2005-02-10 08:01:22
Message-ID: 5066E5A966339E42AA04BA10BA706AE56246@rodrick.geeknet.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> 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. (Note
> that this will actually be worse in HEAD, since a refactoring
> I applied will mean we consume two stack frames for each
> expression.)
>
> A workaround would be to increase PostgreSQL's stack size.
>
> 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:

Just like I showed earlier on large IN () lists are useless....
Instead I use the UNNEST function I posted earlier (see http://archives.postgresql.org/pgsql-hackers/2004-11/msg00327.php) like so:

Select id from table inner join unnest(array[1,2,3,4,...]) as d(id) using(id);

Not only does it not crash the backend,. But it also proved to be faster, tho admittedly not much.

... John

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Meskes 2005-02-10 08:07:43 Re: 8.0 ecpg crashes with "create table as" statement.
Previous Message Neil Conway 2005-02-10 06:41:25 Re: BUG #1473: Backend bus error, possibly due to ANALYZE