Hi,
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 mem=
ory=20
corruption causing that error, so that the query runs fine in a "fresh"=20
postgres process but fails when e.g. malloc() returns a block which has=20
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:
http://archives.postgresql.org/pgsql-bugs/2003-08/msg00051.php
> 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=
=20
hangs for hours until we kill the process.
yours,
- clifford
--=20
: Clifford Wolf =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0Tel +43-1-8178292-00 :
: LINBIT Information Technologies GmbH =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fa=
x +43-1-8178292-82 :
: Sch=C3=B6nbrunnerstr 244, 1120 Vienna, Austria =C2=A0 =C2=A0http://www.li=
nbit.com :
