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

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

From: Neil Conway <neilc(at)samurai(dot)com>
To: "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 06:41:25
Message-ID: 1108017685.1286.186.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Thu, 2005-02-10 at 02:37 +0000, Brian B. wrote:
> I am loading some spam/ham data/tokens, to be used for the dspam anti-spam
> software, into PostgreSQL. After a few hours of inserting and updating the
> existing data, the backend crashes with a signal 10 (bus error). I am also
> running an ANALYZE command to help keep the indexes up to date every 10
> minutes.

As far as I can tell, ANALYZE is not at issue here.

> I have rebuilt PostgreSQL with debugging enabled and have a
> resulting core dump. I am not sure who to send this to, however. The
> backtrace using the core file is as follows:
> #0  0x80c4b52 in transformExpr (pstate=0x86fa630, expr=0x85ec148)
>     at parse_expr.c:81
> #1  0x80c5126 in transformExpr (pstate=0x86fa630, expr=0x85ec1d0)
>     at parse_expr.c:270
> #2  0x80c5126 in transformExpr (pstate=0x86fa630, expr=0x85ec258)
>     at parse_expr.c:270
> #3  0x80c5126 in transformExpr (pstate=0x86fa630, expr=0x85ec2e0)
>     at parse_expr.c:270
> [... repeat above several thousand times ...]

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

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:

foreach (element of IN list)
    ... 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.


In response to


pgsql-bugs by date

Next:From: John HansenDate: 2005-02-10 08:01:22
Subject: Re: BUG #1473: Backend bus error, possibly due to ANALYZE
Previous:From: TANIDA YutakaDate: 2005-02-10 04:05:18
Subject: Re: 8.0 ecpg crashes with "create table as" statement.

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