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

Re: [Sd-log] Re: Endless loop in ExecNestLoop

From: Clifford Wolf <clifford(dot)wolf(at)linbit(dot)com>
To: sd-log(at)lists(dot)linbit(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [Sd-log] Re: Endless loop in ExecNestLoop
Date: 2006-01-30 17:23:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs

On Monday 30 January 2006 17:42, Tom Lane wrote:
> > Version: 8.0.2
> I don't think so ... neither bitmap scans nor slot_getattr exist in 8.0.

oops. it is 8.1.2 ..

> Not a lot.  You need to find out what the difference is between the
> cases where the query runs quickly and those where it doesn't.  I'm
> betting that the planner is choosing a very bad plan in the slow cases,
> but there's not a lot of evidence here to show what or why.

it is exactly the same query. I rather think that there is some kind of memory 
corruption causing that error, so that the query runs fine in a "fresh" 
postgres process but fails when e.g. malloc() returns a block which has 
already old data in it or the stack contains already data from an old stack
fragment. We hunted a bug with simmilar symptomps a while ago:

> Do you have geqo_threshold set to less than its default value?

We have disabled geqo on that system.

> sometimes execute the query with different sets of parameters?
> Either of these might lead to changes of plan.

no. it is exactly the same query that sometimes executes fast and sometimes 
hangs for hours until we kill the process.

 - clifford

: Clifford Wolf                                 Tel +43-1-8178292-00 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria :

In response to

pgsql-bugs by date

Next:From: David FetterDate: 2006-01-30 18:15:57
Subject: Re: [PATCHES] BUG #2221: Bad delimiters allowed in COPY ...
Previous:From: Michael FuhrDate: 2006-01-30 17:12:22
Subject: Re: BUG #2224: unlogical syntax error

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